'GIF Animations and Images' FileType Plugin (.GIF, .AGIF) [Latest v1.5 2021-11-16]

[Ego Eram Reputo]

I've got these archived if you need any of them

 

[midora]

8 hours ago, Pixey said:

I found the v.0.12 and here is a link to download it:  https://www.dropbox.com/sh/t16edlra924d0ts/AADyW3tmcnJFB5o-EmCCkAm3a?dl=0

 

Thanks Pixey. This version has been modified in 2019 to use octree. So I would prefer the v0.11.

[midora]

8 hours ago, Rick Brewster said:

 

If you're looking for a better octree quantizer, you can adapt the code from https://github.com/paintdotnet/PaintDotNet.Quantization

 

Hi Rick. I know. But I guess the main issue is that the process of quantization and dithering should result in similar frames. Octree is for sure quite good for still images but it may not work optimal for animated frames.

 

[Red ochre]

I have ImAGIF.File Type.dll version 0.6.0.816 (for Pdn 3.5.11 - 30/03/2015) if you can't find v11.

 

Dropbox link

[Pixey]

@midora here is the v0.11 in my Dropbox:  https://www.dropbox.com/s/i9nyrrxaewgzhp5/ImAGIF.FileType v0.11.zip?dl=0

 

[midora]

Thanks to all for your help.

@Red ochre yes I would take the 0.6 😉 Older ones make no sence.

A v0.9 would be greate because this one introduced dithering.

 

In the meantime I figured out what's the issue with Pixeys gif. The gif starts with a frame of 256 colors (the gif limit) but adds more and more colors so that the last frame contains more than 10000 colors. This is legal but not supported by the plugin in the moment. Looking to the first and to the next frame you wouldn't expect that these two frames are using 10000 different colors. I'm pretty sure you wouldn't see a big difference if both frames would use the same 256 colors. And the file size would shrink.

At the end you have to find a compromise between encoding speed and final file size.

[Rick Brewster]

12 hours ago, midora said:

 

Hi Rick. I know. But I guess the main issue is that the process of quantization and dithering should result in similar frames. Octree is for sure quite good for still images but it may not work optimal for animated frames.

 

 

You could generate a palette for all frames by writing an IBitmapSource implementation that contains all of the frames as one large virtualized bitmap. Either (width * N) or (height * N). Just feed them all in. Once you have the palette, use it with the QuantizedBitmapSource for each frame individually.

 

IBitmapSource does not need to be a real Bitmap under the hood, so memory use is efficient. It can -- and should -- be virtualized. e.g. if it's asked for row N, assuming you use the (height * N) approach, you provide (row N % individual frame height) from frame (N / individual frame height)

[BajaBrainBlast]

On 11/18/2021 at 9:39 AM, midora said:

Hi @BajaBrainBlast  did you install paint.net 4.3.2?

Anyway you should avoid to fix issues in registry as long as you have not a quite good idea what you are doing.

Downgraded from 4.3.3 to 4.3.2, that fixed it. Thanks for making such a cool plugin, I look forward to using it.

[midora]

45 minutes ago, BajaBrainBlast said:

Downgraded from 4.3.3 to 4.3.2, that fixed it.

 

Works for me in 4.3.3.

[midora]

Added a link to @Pixeytutorial.

[midora]

Six years ago not a lot of applications or browsers accepted files with extension .agif.

This has changed in the meantime. So I would like to share a list of applications which worked without changing back the extension of files to .gif.

Together with ImAGIF.Thumbnail there may be no longer a reason to rename the file.

• firefox
• google chrome
• ms edge
• paint.net (with ImAGIF.FileType plugin)
• gimp

Feel free to contribute to the list. I may add it to the first page.

Edited December 7, 2021 by midora

[midora]

Tip:

After installing ImAGIF.Thumnail you could change in the registry HKEY_CLASSES_ROOT\.agif\PerceivedType from image to video.

Windows Explorer will then no longer show the image shadow instead the .agif image will be decorated with a video frame (for some reason only if width > height).

 

Maybe I will add this feature to the Thumbnail Installer.

[null54]

7 hours ago, midora said:

Windows Explorer will then no longer show the image shadow instead the .agif image will be decorated with a video frame (for some reason only if width > height).

 

The proper way to disable the image shadow is to set the Treatment registry value, see https://docs.microsoft.com/en-us/windows/win32/shell/thumbnail-providers#thumbnail-adornments.

[midora]

3 hours ago, null54 said:

The proper way to disable the image shadow is to set the Treatment registry value, see https://docs.microsoft.com/en-us/windows/win32/shell/thumbnail-providers#thumbnail-adornments.

 

My Win10 registry doesn't contain any 'Treatment' keys and 'PerceivedType' works fine.

[null54]

30 minutes ago, midora said:

My Win10 registry doesn't contain any 'Treatment' keys and 'PerceivedType' works fine.

 

My guess is that all of the file extension handlers you have installed use the OS default adornments for their PerceivedType, the Treatment key would only be created if a thumbnail handler needed to override the OS default thumbnail adornments.

 

You could change your installer to create a REG_DWORD key at HKEY_CLASSES_ROOT\.agif\Treatment and set the value to 0, this would tell the OS to not use a drop shadow for that image format.

If you want to force the image to use a video frame, set the Treatment value to 3.

[midora]

The ImAGIF installer sets the PerceivedType to 'image' in the moment as defined in https://docs.microsoft.com/en-us/windows/win32/shell/app-registration?redirectedfrom=MSDN (that's why the thumbnails are getting the drop shadow).

 

But if I'm changing the installer in the future to allow the user to select the kind of thumbnail decoration I will also check out if Treatment works as described.

 

Maybe Treatment sets the default and PerceivedType overrides it.

[null54]

1 hour ago, midora said:

Maybe Treatment sets the default and PerceivedType overrides it.

 

I think it is the other way around.

[midora]

32 minutes ago, null54 said:

I think it is the other way around.

 

this would mean that's OK in the moment and the installer should always set PerceivedType but let the user override it by setting Treatment.

[midora]

I guess the main issue setting Treatment in the Installer is that it requires a ProgId.

HKEY_CLASSES_ROOT
   .{ProgId}
      Treatment

This would mean applications like paint.net could override the default decoration of the thumbnails.

[Tomsha]

Dear @midora,

 

I'm having an issue when I save an animated gif, the size of the image changes from the original file.

I need to save the animated gif exactly as 112x112.

Any idea why this is happening? Any workaround?

 

For example, the original of this was 112x112 but comes out as 100x110 when saving.

 

 

Thanks,

Tom.

[midora]

Hi @Tomsha the gif you added to the forum is 112x112. Also resaving it from paint.net created a 112x112 image. So please check again. What are the dimensions paint.net is showing in the status line before you are saving the file? What are the settings you are using in the save dialog?

 

Edited December 15, 2021 by midora

[midora]

There is an additional info which people should know.

 

If the first frame of a gif is surrounded by a transparent area and you are loading it into paint.net without changing the name to .agif then you will get the first frame without the transparent area (means the image dimensions are smaller).

 

The reason seems to be an issue in the WIC (Windows Imaging Component) which is used from paint.net and the WindowsExplorer. WIC returns the dimensions of the first frame and not the logical screen size. Difficult to say if this is a bug or a feature. The Windows Explorer thumbnail also removes the transparent area and shows the smaller dimensions in the tooltip. I never reported it to Rick. A typical example is the deen gif which I posted earlier.

[Tomsha]

@midora Maybe I uploaded the wrong one but I tried again and getting the same results.

I did suspect it had something to do with the "unused" transparent background.

I thought it might be the tooltip only but when opening again in paint.net I get smaller dimensions.

 

This is the process(sorry for a lot of screenshots):

 - Original file:

  

Saving:

Result:

 

I hope this clarifies it.

 

Thanks,

Tom.

[midora]

I tried to explain that this is a WIC issue. If you rename the file to .agif and open it in paint.net the size of the canvas will be 112x112. Every browser will play the file with a size of 112x112.

 

I guess the only chance to avoid this issue in Windows Explorer would be to add a save option which tells the plugin that the first frame should not be optimized to the minimal size. This may increase the file size a little bit but not a lot.

 

[AndrewDavid]

The first 12 columns are blank. Add 1 line of black in column 1 in bottom layer, add one square to top and right. Issue resolved to maintain size as gif.