Yes I have. Notice the nothing added emphasis above.
This applies to the core substance.
On top of that it may appear versatile.
That's the essence of modernization.
It can't be different, because microscopy is an artificial application.
The common raw formats are not any better, because they lack two thirds of the image information due to the inferior (color filtered) sensor technology.
True images could only be taken with Foveon X3 sensors.
I have no problem with WebP, HEIC, AVIF, because they don't pretend to be JPEG.
I have a problem with "JPEG XL" pretending to be JPEG, what it isn't.
It's a shame that the WIC plugin is crap. If there are any major updates I'll update my plugin. The main thing missing is HDR, but that is waiting on DOpus.
It can't be different, because microscopy is an artificial application.
On the contrary. This isn't tinkering with sample images and internet memes. You only realise the limits of a format when you have 300 40-megapixel images you need to encode and navigate relatively quickly, need it to support multiple layers, where you absolutely cannot allow colour banding or fringing - and still need to fit it all in a couple of terabytes, AND you need others to open it without a specialised file viewer. AND you need to be able to convert that to lower res JPEG for a journal without secondary loss.
DOpus now supports three ways of handling JXL - external tools, the plugin, and the WIC. The latter two have the advantage of metadata. I can open a drive with 6000 images with algorithmic names and use DOpus to navigate them quickly and easily. You cannot know how useful I find this.
I have a problem with "JPEG XL" pretending to be JPEG, what it isn't.
JPEG is a group. If there are politics around your assertion, this really isn't the place. I am an end-user. The "JPEG XL" fileformat fits my needs perfectly where others don't - today.
A little update. V0.11 of libjxl has been released. I might get around to implementing it one day, but it seems like maybe better options are coming, and until HDR support is available I'm not in too much of a rush.
32 bit versions could crash with a malformed jxl file. I build for x64 anyway so I don't think it's a major problem. If in doubt, don't view jxl files from the internet.
I'll stick with your plugin for now. It's still considerably faster than the Windows WIC driver.
Good point. I actually wanted to ask if this plugin is still relevant. I assume it should be deprecated, since the WIC driver supports this image format.
Strange that it is faster. Did Microsoft mess up that badly?
Last time they changed the way you call into libjxl. It might not have changed this time, I haven't looked. Feel free to though, and submit a pull request.
I think they are looking at Rust because it's the new security hotness. I read that's what Mozilla, Apple, and now Google have adopted.
I think Windows WIC are always slower because they pull through the shell thumbnailer, but I could be wrong about that and it's just because the code is unoptimized. It's certainly NOT because it supports HDR... because it doesn't... or transparency. We should be glad at least it supports the lossless compression mode because the HEIC one doesn't.
Oh, and those who want to (or have to) use Windows 10 will have to use the plugin, because the JPEG-XL WIC is only part of Windows 11.
I think Windows WIC are always slower because they pull through the shell thumbnailer, but I could be wrong about that and it's just because the code is unoptimized.
Microsoft says they use libjxl, thus the performance and features should be the same, in theory. But maybe the way how WIC driver is integrated introduces overhead.
Oh, and those who want to (or have to) use Windows 10 will have to use the plugin
Yes, it is a pity. Microsoft still supports Windows 10, but they do these shenanigans to "encourage" people to switch. There are absolutely no technical reasons why the WIC driver should not support Windows 10.
