This plug-in is for DOpus, it won't show anything in Explorer.
Apologies.
First sentence should be:
Picture shown in Viewer but not in Viewer Pane and thumbnail is generated in DOpus but not in Explorer.
I just copied it from thread titled" Picture shown in Viewer but not in Viewer Pane".
I mentioned Explorer to exclude possibility that there is other component (e.g. WIC codec) involved.
And picture is not displayed if in archive.
I was going to write that Explorer and DOpus thumbnails are separate, but I realised you already know this.
As I said in your other thread, it may be another plugin trying to open the file. The MetaPlugin is often the culprit.
Try opening a JPEG-XL with D8Viewer, which should be in the DOpus directory - just right click the image, Open With, Choose Default Program, and select D8Viewer in the DOpus directory.
If it fails to open, which it should if it isn't working in the preview panel, then it should tell you which plugin is being used to try to open the image.
I don't think this is an issue with the plugin. The API is very simple and I didn't see anything about the viewer pane in there when I looked before. I think xraale is probably right, it's more likely to be some kind of Opus or other plugin issue.
It opens in Viewer both after double clicking or using Open With, Choose Default Program, and select D8Viewer method.
I have disabled other plugins for test and I have restarted Opus. I do not see MetaPlugin. I think that it is not installed with DOpus 12.
MetaPlugin comes with DOpus. It's listed as MetaPlugin (Preview/Office/Web/ActiveX).
If it isn't there, then there's something very wrong with your installation and could explain your issues. You could try uninstalling DOpus completely and re-installing it.
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