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