If the MetaPlugin isn't installed, you won't get previews of many types of file, like PDF, or anything handled by Windows shell.
But I've just tested by disabling it and the JPEG-XL plugin still shows the image properly in the preview window.
MetaPlugin had a different name in Opus 12.
Right, sorry. It was just called ActiveX+Preview+Office+Web.
If Konrad_Klar is getting the DOpus viewer to load JPEG-XL then the plugin appears to be working, at least.
I can confirm. I moved a picture to Libraries/Images and nothing shows in the viewer pane any more. Just white.
Looks like a bug in the plugin. I don't think it's in dopus. I've just tried it with a JPEG2000 and WebP file (different plugins) and they show ok.
1 Like
For me too, but not if picture is selected from listers like lib://Pictures or lib://Documents.
It specifically doesn't work for libraries. I've tried file collections, favourites, and search results, and the plugin works fine. Filesystem is ok too.
But use a library (which is lib://something in dopus) and preview window will be blank. Thumbnails still work.
It looks like a simple pathing bug. Maybe the JPEG-XL plugin is asking dopus for the path and getting something back that fails to resolve to an actual file.
Yes, that makes sense, some issue with unusual paths. You can see the function that loads the file here: JPEG_XL_dopus/jpegxl/jpegxl.cpp at main · kuro68k/JPEG_XL_dopus · GitHub
It's pretty simple, and uses the standard library functions for reading the file in. Supports Unicode, and I have tested it with non-English paths and file names.
Not sure why that would fail. Can you build it yourself? You can use Visual Studio Community. Then maybe you can add some debug output to see where it is failing. I don't use libraries at all.
Thanks for the source, I should have taken a look at it sooner. It looks like it already has debug.
fwprintf(stderr, _T("couldn't load %s\n"), lpszName);
I'm afraid I have no idea where dopus sends stderr, if indeed anywhere. I tried the little dopus.exe >stdout.txt 2>&1 trick, but it's just an empty file, so either this doesn't work or the plugin isn't actually failing to find the file.
It's all very odd..
Yeah, I don't know where it goes either I'm afraid. One for Leo... The alternative is to just write it to some specific file. Could add a debug function that handles it.
When it is a normal file path then DVP_IdentifyFileW is called and after that DVP_LoadBitmapW.
If it is a libary path then DVP_IdentifyFileW is called and after that DOpus tries to call DVP_LoadBitmapStreamW.
But the jpegxl plugin has no DVP_LoadBitmapStreamW, so no picture is shown.
But is DVP_LoadBitmapStreamW really needed for library paths or is this an error of DOpus?
And if the Stream functions are needed for library paths, why is called DVP_IdentifyFileW before and not DVP_IdentifyFileStreamW?
Well spotted Nosh. It wouldn't be difficult to implement stream loading I think, I might look at it next time I update libjxl if I can find a good test case. I don't use libraries so I'd have to set one up.
Or feel free to submit a patch. All you really need to do is copy the stream into a buffer and then do a bit of refactoring.
We'll change this in the next beta, so library paths don't send things down the stream codepath.
That said, it's worth adding support for streams anyway, as it enables viewing files inside archives. Since these images will be fairly small files, you could extract them to a temp file and load that, if it's easier than making the code use streams directly. (Sometimes that's easy, sometimes it's hard, depending on how the decoder library is written.)
The LeoHelpers::FileAndStream class in my plugin source code gives you a really easy way to turn a stream into a temp file that it cleans up automatically, so you can make the Stream functions a thin wrapper that than calls your normal file code. (This works great for small files. OTOH, it wouldn't make sense for large files like videos.)
5 Likes
V0.11 of libjxl is out, but it doesn't seem to contain anything of interest so I won't bother updating.
Note that libjxl now comes with a warning about it being pre-release and there being potential security issues. Don't use it on untrusted files. The ideal use-case is where you have created them yourself.
About streams, I too a look, it wasn't trivial and I don't use them, so I probably won't support them. The whole situation with JXL is disappointing. Google ditched it because it's beta and not improving very quickly, so it probably won't become a web standard for a long time yet. There are no mature software implementations. It's useful for archival (you can losslessly transcode JPEGs to JXL) but beyond that it's of limited value.
I agree it's disappointing that JPEG-XL seems to be going the same way as JPEG 2000. But we just can't go on using JPEG forever, it's way too limited.
I've seen HEIC/AVIF but using a video codec on still images just results in an unwanted soft blur as far as I'm concerned. And WebP, the most successful JPEG replacement? I wonder how long it'll last when Chrome ships with no ability to adblock with this Manifest V3 and its bleeding users to Edge.
I still use microscopes that can save in JPEG 2000 format, which produces images much smaller than PNG or TIFF, with much less loss than JPEG. The only reason I can use this format is because Directory Opus has a JPEG 2000 plugin. If I get updated software that can save JPEG-XL, then I'll be able to use it because of your plugin.
I think I read Leo once that it's not worth supporting most new image formats because almost all of them fail to get support. But DOpus now supports JPEG-XL at least and that's because of you. You are making a difference 
1 Like
Thanks for the kind words.
It's hard to say if JXL will take off or not. The fact that you can losslessly transcode JPEGs to it is a big advantage. Also Apple now supports it for photos take with an iPhone, and on MacOS, so it is probably going to get at least some traction.
FWIW I've been using my plug-in quite a bit lately and it seems to be stable and perform reasonably well. I don't know what code Apple is using but libjxl still comes with warnings about it being beta, possible security issues etc. I heard there is a Rust reference implementation now, but I haven't looked at it.
1 Like
Thank you very much, mojo-chan, for creating this plugin! It works quite well, although not as fast as the native JPG integration. I really hope that JPEG XL gets native support in DOpus soon now that the new iPhones support the format.
Unfortunately it probably won't be as fast as JPEG for the foreseeable future, unless the reference implementation dramatically improves or a better one comes along.
I wouldn't get too excited about iPhone support either, because DOpus doesn't support HDR so anything taken with a capable camera, like an iPhone, won't look very good when viewed that way. Even if you don't have an HDR monitor, it requires the app to pass the HDR data to the OS for proper display, otherwise it's just a generic approximation and not specific to your monitor.
Then let's hope that they improve the reference implementation. Good point regarding the HDR support. We will see.