[Feature Request] Add support for newer image formats

[rohan-gt]

Hi, is it possible to add support for newer image formats like AVIF, HIEC, JPEG XL etc.?

[maforget]

Possibly at one point.

But are there any content using these? All this depends on existing library support for these file types. Right now except DjVU or WebP that uses external library most of the format are the one used by .NET.

Using ImageMagisk might be a solution.

[5h4k3]

This could be an interesting addition. All my comics are now in AVIF format. This allowed me to go from a 100MB Comic to a 5/10MB one, even less sometimes while maintaining high quality (according to my taste). As a result, my entire database is on my tablet.

To achieve this, I use ComicRack-Plugin-MIFS (Modern Image Formats Support) with CR OG but unfortunately this plugin doesn't seem to work with CR CE…

So for now I'm still on Comicrack Original.

PS: I don't know if the plugin could be hard to make it viable, it seems a little bit hacky and it's "just" a decoding plugin, it doesn't add anything to CR's export/conversion integrated functions.

[maforget]

Interesting technique. I had the idea to use Harmony already to use with scripting, but injecting the code on launch is a way better technique than what I was doing with my RAR5 Pack.

That being said, it's could be very possible to basically copy/paste the code and integrate it easily. This is basically the way WebP & DejaVu are implemented, they are just converted to JPEG internally. So this would need to taken into account when patching issue #74 .

Also I believe the reason it isn't working is that it references the original dll, which are signed. ComicRackCE aren't so the signature isn't the same. Just a rebuild with the correct dll should do the trick. Although the dll version changes every build, I don't know if that is that important for Harmony.

Although if I were to implement this I would look for the source of these native libraries. If we could find libraries that would also create the files, it could be added to the export feature.

[maforget]

Depending on when you tested that plugin, one reason it will not work anymore, is that I changed the signature of one of the function that is fixed by the Harmony patch. I needed to access the size, so I changed the string to a ProviderImageInfo. Patch will need to be updated for that.

[maforget]

I've added support for Decoding & Encoding AVIF & HEIF.

I've only added binaries for 64bit. I didn't want to bother since this already adds 4 libraries to the Resources folder. I don't know if it's worth the trouble these days on modern computer, that are all 64bit. If you are running in 32bit you won't be able to read & export to these formats.

The HEIF format is only a container and as all kind of different subformats it supports. Things like 10bit images, sequences, etc. The images this creates are in 8bit and may or may not support any of these extra features. Finding images for testing seems hard so I can't tell if all the different format will work. ComicRack will read .heic, .heif & .avif extension types. It uses a function from the libheif library to read the images header and determine if it can read the file. Some format aren't supported.

See code related to the header detection here:
https://github.com/strukturag/libheif/blob/15ff08fea0695624c875ab92f48556d67fb453f0/libheif/api/libheif/heif.cc#L103-L146

I believe some iPhone pictures may be in mif1 or mif2 format, which the library says it's a maybe. But I don't try to read maybes, so they may not work.

If anyone can test it with various files. I also still need to add support for JpegXL. So I will leave this open.

[SteveHutchinsASBFA]

I'm wondering if JPEG XL is still on the table. I see it as "coming soon" in the read me and left open here, but closed as "not planned" in the other thread.

I'm not at all being pushy; I understand this is a hobby project. But I would like to convert my collection to JPEG XL and if it is still planned, I'll just wait. If it's no longer planned, though, I will move in another direction.

[maforget]

That other issue was closed because it was a duplicate of this one.

I do have the intention of adding it, there is already some code regarding the JPEG XL support. To implement HEIF/AVIF I've used code from this user repo 0xC0000054, who creates image format plugin for Paint.NET, including JpegXL. He had a wrapper for the libheif library and I assumed there was one for JpegXL also, but he didn't. So I would have to check his plugin to figure out how libjxl works to create my own wrapper or find another. Which is more involved than subscribing to a package on Nuget and adding a couple of line of code. So I put it on the back burner.

Later there was a discussion related to this on Reddit and someone did reply that it may not be worth it since it pretty much a dead format. What is your reasoning for using JpegXL files instead of HEIF/AVIF/WEBP? Are there even files that exists in that format or are there any other reader that support it? So if it's all for use in ComicRack why not use something like HEIF/AVIF/WEBP anyway?

My initial idea was to pretty much immediately add support for it, but that got stopped when I figured out I was missing the wrapper. I am sure another exists somewhere or I could figure it out, but then I though is it worth it? There is already some pretty good image format, with HEIF/AVIF you can have a very small file size with only 40% quality. I was able to go from a 4.6GB file to 182MB using AVIF. Not sure how JpegXL compares.

Usually I add something either because something bothers me or I really want it, there is a bug, someone request is a quick fix or I want to figure out how to do something. With the HEIF/AVIF added I had achieve my goal and didn't have any motivation left because of the extra work required for JpegXL. That and all the games that came out at the end of 2024 had me so busy. Just Satisfactory, Factorio & POE2 are responsible for a huge chunk of my free time.

[SteveHutchinsASBFA]

Thank you for the detailed response! Basically, I'm no expert on image formats, but I want what probably everyone else wants: the best image compression with the best quality. Researching it, it seems like AVIF and JPEG XL are the best with most sources saying JPEG XL comes out a bit ahead. BUT AVIF is comparable.

What intrigued me about JPEG XL over AVIF was the lossless compatibility with JPEG classic since the vast majority of my collection is in that format now.

Having said all that, everything I read also said JPEG XL's future is challenging at best, so it's right to be suspect of it as a viable future format.

I hear you on being attracted to a challenge and also focusing on what the program needs and what most want. I wouldn't shed a tear to go with AVIF, just curious if I should pull the trigger or not.

Enjoy those games! =)

[mids33]

hi maforget its a chance to thank you alot for your work on ComicRackCE..
about JPEG XL (jxl) i start getting a couple of jxl format daily from japanies comics..
ImageMagick\modules\coders\IM_MOD_RL_jxl_.dll not sure if this consider a plugin or useful for you
if you need images for testing :
mogrify -format jxl *.jpg

take care and thanks again

[Amalith0]

Would like to also express my interest in support for jpeg xl if you ever feel up to it (possibly after someone makes an applicable wrapper or whatever). Chrome very recently has merged in support for jpeg xl, which I'd say is a reasonable sign the dead format accusations are somewhat overstated, especially as they were the original blocking force mitigating widespread adoption sort of (format standardization drama)

Specific reasons for preferring the format over avif/webp include that jpeg xl often has superior compression in several cases and most crucially can be converted to from jpeg with 0 quality loss. As a personal factor I also prefer it from the standpoint of having good lossless and lossy compression compared to avif/webp which from my understanding are only particularly good at lossy/lossless respectively.

[gdartillero]

Any news on this please?

[maforget]

Test build for JpegXL in #244. Only for 64bit.

To use lossless mode, you need to enable the JpegXLEncoderLossless setting in ComicRack.ini (or use -JpegXLEncoderLossless:true) as a command line switch.¨ Setting moved to the Export Dialog directly.

You can also change the effort via JpegXLEncoderEffort setting in ComicRack.ini (or use -JpegXLEncoderEffort:7) as a command line switch. Valid value are from 1-9 (higher is better compression but slower).

There is also the Quality setting (set in the export dialog) that comes into play when not using lossless mode. It transforms the value to a distance setting used by the encoder, using this formula (100 - quality) * 0.1. Recommended is 0.5 to 3.0, so 70% = 3.0 & 95% = 0.5.

Here are some quick file size test I did (all at the default effort 7).

Desciption	File Size
Original JPEG	107 MB
Lossless	85 MB
Lossy (70%)	45MB
Lossy (50%)	32MB

There are still plenty of others settings to go though (for encoding) so some feedback is welcome. Any test files could be welcome to test using various configuration.

There is a setting called uses_original_profile that seems to embed the original color space instead of simply sRGB, it's to be used for lossless images. But the file size goes up by 250% (85 MB to 200MB). I don't think it is worth it, since it also requires special color decoding not implemented.

• Ref: https://libjxl.readthedocs.io/en/latest/api_metadata.html#_CPPv4N12JxlBasicInfo21uses_original_profileE
• Ref: https://github.com/Dwedit/JxlSharp/blob/f35ea2e044263423416c6afab87f6676bb87b93e/JxlSharp/JXL.cs#L668-L671