AVIF FileType (11-15-2024)

[null54]

This plugin allows AVIF images to be loaded and saved with transparency.

 

This plugin is bundled with Paint.NET 4.2.14 and later.

 

If you need the features from a newer version you can still install the plugin.   
The plugin will override the bundled version if it has higher version number.

 

Compatibility: 5.1+

 

Installation:

 

1. Close Paint.NET.
2. Place AvifFileType.dll, AvifNative_ARM64.dll and AvifNative_x64.dll in the Paint.NET FileTypes folder which is usually located in one the following locations depending on the Paint.NET version you have installed.

  Classic: C:\Program Files\Paint.NET\FileTypes    
  Microsoft Store: Documents\paint.net App Files\FileTypes

  Portable: <Paint.NET folder>\FileTypes

3. Restart Paint.NET.

 

Download:

 

AvifFileType.zip

 

Source Code: https://github.com/0xC0000054/pdn-avif

 

[null54]

Released beta version 0.6.0.

 

Changes:

• Reduced memory usage when loading files.
• Added support for loading image grids.

[null54]

Released beta version 0.7.0.

 

Changes:

• Add support for negative crop offsets
• Improve error reporting
• Reduce memory usage when saving files

[olavrb]

Thank you very much for this FileType plugin. Looking forward to start experimenting with AVIF.

• Is lossless supported/ is quality slider at 100% lossless?
• Would it be feasible to implement a bit depth option when saving an image?

[null54]

4 hours ago, olavrb said:

Is lossless supported/ is quality slider at 100% lossless?

 

Lossless is supported, but the RGB to YUV conversion is lossy (see https://github.com/joedrago/colorist/issues/26 for more details).

 

4 hours ago, olavrb said:

Would it be feasible to implement a bit depth option when saving an image?

 

What do you mean by bit-depth?

If you are referring to bits-per-channel, Paint.NET only supports editing in 8 bits-per-channel.

[Rick Brewster]

Probably means like this 

 

 

The auto-detect code is a pain, but extremely useful, I can probably find a way to make it available for plugin use

 

[null54]

22 minutes ago, Rick Brewster said:

Probably means like this 

 

My code already uses auto-detection for the bit depth, it ignores the alpha channel if it is opaque.

Gray scale (monochrome) support is possible, but when I tested it using cavif the monochrome encoding option it only saved 3 bytes vs a gray scale image saved as 24-bit.

[null54]

Released beta version 0.8.0.

 

Changes:

• Added support for lossless encoding of color and gray-scale images
• Reduced the file size when saving gray-scale images
• Reduced the file size when saving images with transparency
• Added XMP metadata support for Paint.NET 4.2.11
• Reduced memory usage when loading images

Note that this release requires Paint.NET 4.2.11 or later.

[olavrb]

libavif released v0.7.3 with native lossless support, might be helpfull?

• https://www.reddit.com/r/AV1/comments/gdi12d/libavif_v073_tagged_including_native_lossless_mode/
• https://github.com/AOMediaCodec/libavif/releases/tag/v0.7.3
  • Changelog: https://github.com/AOMediaCodec/libavif/blob/master/CHANGELOG.md

[null54]

5 hours ago, olavrb said:

libavif released v0.7.3 with native lossless support, might be helpfull?

 

I already added lossless support in version 0.8.0.

[null54]

Release version 1.0.0.

 

Changes:

• Upgraded to libaom v2.0.0
• Allow lossless images to use an ICC color profile
• Improved performance when loading and saving images
• Fixed the AV1 chroma sub-sampling fields for YUV 4:2:2
• Reject images with unsupported essential properties
• Attempt to preserve the color conversion data for loaded AVIF images

I did not create a new thread in the plugins forum due to the additional steps that are required to install this plugin.

[null54]

Release version 1.0.1.

 

Changes:

• Changed the target framework to .NET 4.7 to allow for bundling with Paint.NET

[xpclient]

Thank you very very much! This is extremely awesome to have a plugin without any Store codec dependency. Although the resulting file size is still larger than the super compact size produced by IrfanView's WebP plugin despite Best compression, 85% quality and Slow compression mode.

Edited June 29, 2020 by xpclient

[null54]

19 hours ago, xpclient said:

Although the resulting file size is still larger than the super compact size produced by IrfanView's WebP plugin despite Best compression, 85% quality and Slow compression mode.

 

WebP and AV1 are different formats, so it is not surprising that there would be a size difference with the same settings.

[Seerose]

❤️ @null54!

 

Thank you so much.  

[xpclient]

On 6/30/2020 at 4:37 PM, null54 said:

 

WebP and AV1 are different formats, so it is not surprising that there would be a size difference with the same settings.

Oh I know they are entirely different compressions. I just somehow got the (wrong) impression that since WebP's around for a long time and with a BSD license, AVIF being based on AV1 was somehow supposed to outperform WebP,  not just JPEG or that was the whole point of it.

Anyway, WebP has a major Achilles heel - metadata. Google provides no tools for managing or displaying WebP metadata although it is possible and documented. Hopefully due to Microsoft supporting AVIF in Windows, it won't be a problem with AVIF.  

[null54]

Release version 1.0.2

 

Changes:

• Changed the FileType name to AV1 (AVIF)
• Fixed an issue with preserving the AVIF color conversion data
• Disable row multi-threading when encoding with a single thread
• Reduced the native DLL size
• Fixed a potential memory leak

[Rick Brewster]

On 7/3/2020 at 1:45 AM, xpclient said:

Anyway, WebP has a major Achilles heel - metadata.

 

Another is that it's limited to 16,383 x 16,383 pixels 🤦‍♂️

[null54]

On 7/3/2020 at 2:45 AM, xpclient said:

Google provides no tools for managing or displaying WebP metadata although it is possible and documented.

 

Not true, the webpmux sample utility can be used to add and remove WebP metadata.

But I do not think that either the Microsoft or Google WIC decoder supports reading the EXIF/XMP metadata.

 

1 hour ago, Rick Brewster said:

Another is that it's limited to 16,383 x 16,383 pixels 🤦‍♂️

 

That is a limitation of the VP8 compression format that WebP uses, I have no idea why a video compression format released in 2008 would only use 14 bits for the image width and height.

[Seerose]

❤️ @null54!

 

Thank you so much. 🧁 

Edited August 2, 2020 by Seerose

[art926]

Thank you so much for this plugin, it works great! I hope they will optimize the underlying libraries (and hopefully make it run on GPUs) in future so it works as fast as other image formats.

One little thing I've noticed - Windows' Paint doesn't seem to care about the exported color profile in those avif's. Maybe you could add an option to attach or ignore color profiles. Also, GIMP shows some error/warning when I open files, exported by this plugin. Browsers don't complain though.

[null54]

42 minutes ago, art926 said:

Windows' Paint doesn't seem to care about the exported color profile in those avif's.

 

The color profile is being exported, so that may just be another bug in Microsoft's AVIF codec.

 

1 hour ago, art926 said:

Also, GIMP shows some error/warning when I open files, exported by this plugin.

 

It looks like libavif is failing to load the property associations for the alpha channel image.

[null54]

Release version 1.0.3.

Changes:

• Fix the property association box size for images with alpha
• Add forum and GitHub links to the UI

[art926]

On 8/15/2020 at 3:56 AM, null54 said:

The color profile is being exported, so that may just be another bug in Microsoft's AVIF codec.

Yeah, the decoder is probably buggy, but here is what's strange though - if I have a standard simple image in .png without an associated profile (should be sRGB profile by default then, right?) and save if into .avif using your plugin, it gets a new profile attached, and then probably Win Paint just ignores it and when I open both - original .png and the exported one in Win Paint, the contrast difference looks like day and night. I remember I saw a similar issue when used GIMP to export to .avif, but it wasn't happening when used a command line tool (forgot its name) instead. So, it's something about No profile -> saved with some added profile -> opened in a viewer that doesn't care about the attached profile. I understand it's more like an issue with the viewer, but what I don't understand - if the original image didn't have a color profile or had some specific one, why would it change at all after exporting to .avif?

Another thought about it - when I was re-encoding videos from my old GoPro I also noticed issues with contrast differences, and I think the reason there was a specific color space that didn't use levels below some (16 I think?) and above some (235 or something like that), so it wasn't like full RGB. It's nothing to do with .avif (I was re-encoding that to h265 I think), but the root cause can be similar. When I save my lossless .png to very high quality .avif's, I want to be sure that it preserves the original color profile/space (or lack of it) and doesn't cut/stretch any levels.

Edited August 16, 2020 by art926

[null54]

3 hours ago, art926 said:

if the original image didn't have a color profile or had some specific one, why would it change at all after exporting to .avif?

 

This plugin tags any image that does not have an existing color profile as sRGB when saving the EXIF data to the file, Microsoft's decoder may be telling WIC that there is a sRGB profile based on that tag.

 

4 hours ago, art926 said:

I think the reason there was a specific color space that didn't use levels below some (16 I think?) and above some (235 or something like that), so it wasn't like full RGB.

 

This plugin does not use the limited color range (16-235), it always uses the full RGB color range (0-255).