Not sure this is possible. Maybe the action would look like:

1. Build
2. Register the dll
3. Run tests with WIC APIs for image viewers

https://github.com/libjxl/conformance is a good resource for reference tests.

The installation instructions for the .dll file seems to only be found on the releases page as the description for the Initial release.

Maybe we could move these instructions over to the README.md so it's more visible, especially as more releases pile up and it might get harder to see the instructions?

Thank you!

bspv1tbgtep000.jxl.zip opened with v0.2.0 and v0.1.19:

mario_chunli.jxl.zip in NeeView:

Maybe this is due to the lack of support for AVX2 and FMA instructions on my processor.

Issue is in jxl-oxide (or maybe libjxl encoding, hope not)
See: tirr-c/jxl-oxide#268

I'm experiencing some confusion with the installation on Windows 11. The application seems to open the old Windows photo viewer, which I wasn't aware still existed.

When I navigate to the destination using the new Windows photo viewer (referred to as "Microsoft Photo"), the JXL doesn't appear. Could it be that Microsoft Photo is no longer utilizing WIC? Is WIC deprecated in this context?

Edit: Dropped the thumbnail question. It required a restart to take off.

it can open jxl files only if i rename them to jpg. But it's impossible to assign .jxl to microsoft photos, only to old windows photo viewer. There is no jxl option in file associations

I saved some images in the JPEG XL format using Affinity Photo 2. I installed jxl-winthumb, and while the images open with Windows Photo Viewer, they are displayed as if they are sRGB encoded. The images are actually in a wider color gamut space, and the ICC profile should be correctly embedded given that if I open the images in Affinity Photo 2 they are in the correct color space. It seems this plugin is having issues with reading or properly utilizing the embedded ICC profile.

I did some testing. You can't call it "testing" though. I was just reading cbz-comics using NeeView. And I noted that the CPU load when decoding images with the latest nightly build of jxl-winthumb is noticeably higher than with v0.1.9. I compared the same files on both dlls.

I understand that there must be differences since v0.2.x did start using jxl-oxide, but I hope there is still room for optimization.

Removing GetColorContexts implementation solves the issue, but

1. How does it cause that?
2. Why can't GetColorContexts fix #29 ? What's wrong there?

Experimenting in https://github.com/saschanaz/jxl-winthumb/tree/winrs-implement, but blocked by microsoft/windows-rs#1094.

But given that microsoft/windows-rs#1080 is now fixed, the boilerplate may still be able to be implemented manually.

https://blogs.windows.com/windowsdeveloper/2017/04/13/com-server-ole-document-support-desktop-bridge/

Sounds doable, but not quite sure yet.

Hello,
The dll works but it's super slow. And there is some freeze of explorer.
After enable it, the process COM Surrogate take 100% of 1 thread of my cpu, all the time.

Most JXLs preview just fine. This particular one does not. Any clue?

screenshot0009_GIGA_(JPEGXL_d2_s7).jxl.zip

Some old softwares has only x86 version, it would be better to support those softwares.

Why does not it show the resolution of the jxl picture?

It would be great if the DLL file had some version info to make it easier to create reliable detection methods for install scripts and similar.

PS > Get-ItemPropertyValue -Path '.\jxl_winthumb.dll' -Name 'VersionInfo' | Format-List

OriginalFilename  :
FileDescription   :
ProductName       :
Comments          :
CompanyName       :
FileName          : <redacted>\jxl_winthumb.dll
FileVersion       :
ProductVersion    :
IsDebug           : False
IsPatched         : False
IsPreRelease      : False
IsPrivateBuild    : False
IsSpecialBuild    : False
Language          :
LegalCopyright    :
LegalTrademarks   :
PrivateBuild      :
SpecialBuild      :
FileVersionRaw    : 0.0.0.0
ProductVersionRaw : 0.0.0.0

PS >

That should at least simplify the build requirement.

The extension works great in all the windows applications, but thumbnails don't show in windows explorer.
I tried installing and refreshing windows explorer, changing directories, still doesn't show *.jxl thumbnails.
I also tried installing older versions of the extension and no luck. I have not found any solution yet, is there anything I'm doing wrong?

Please add support for 32-bit programs to this software! The only program I need jxl support for doesn't have a 64 bit version.

Windows Explorer displays JPEG metadata using Details Pane in main window or Details tab in Properties window.
It seems possible to add it for custom format using Property Handlers: https://learn.microsoft.com/en-us/windows/win32/properties/building-property-handlers

I have recently started converting many PNG files to JXL for compact long-term storage. Since I still want to be able to see what each file is, I naturally was interested to install this piece of software.

However, some images, after being converted to JXL, can not be previewed at all by this software. There is no thumbnail, and the Windows Photo Viewer refuses to open them. Other programs, such as Krita and the official JXL decoder "djxl.exe", have no issue. That at the very least means that the files themselves aren't corrupt.

I'm not sure how I can help other than to upload some of these anomalous files.

I'm using v0.2.2 on Windows 10 Pro, version 22H2, build 19045.3324.

anomalous-jxl-files.zip

I am unable to register jxl_winthumb.dll, and I keep getting the following error message:

The module "jxl_winthumb.dll" was loaded but the call to the DllRegisterServer failed with error code 0x80004005.

I am running the terminal as Administrator. I have the 64bit version of Microsoft Visual C++ Redistributable for Visual Studio 2019 installed on a 64bit Windows OS, and I'm using the latest version of jxl_winthumb.dll (v0.1.12).

As well as testing this on my main system, I also tried testing in a virtual machine with a fairly clean OS (to rule out any clashes with existing installed software).

However, I am using an older version of Windows (Windows 7 Professional 64bit with Service Pack 1) but I've never had any issues with various other Explorer shell extensions that I've tested in the past for displaying thumbnails and metadata (whether it be for image files, audio files, or video files).

It's been nearly a year since the update, and the project currently fails to compile on Windows 11 using 1.7.0 stable-x86_64-pc-windows-gnu and msys2's CLANG64 package mingw-w64-clang-x86_64-rust.

My three points of interest for an update to jxl-winthumb are to

• Fix errors due to building on newer versions of Rust
• Update libjxl from 0.6.1 to 0.8.1
• Remove the asciidoc dependency (seems unnecessary?)

The errors are as follows:

  [ 73%] Built target jxl_enc-obj
  [ 73%] Built target jxl_dec-obj

  --- stderr
  CMake Deprecation Warning at third_party/brotli/CMakeLists.txt:5 (cmake_minimum_required):
    Compatibility with CMake < 2.8.12 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.


  -- Compiler is not EMSCRIPTEN
  CMake Deprecation Warning at third_party/sjpeg/CMakeLists.txt:1 (cmake_minimum_required):
    Compatibility with CMake < 2.8.12 will be removed from a future version of
    CMake.

    Update the VERSION argument <min> value or use a ...<max> suffix to tell
    CMake that the project does not need compatibility with older versions.


  CMake Warning at CMakeLists.txt:378 (message):
    sphinx-build not found, skipping rtd documentation


  CMake Warning:
    Manually-specified variables were not used by the project:

      CMAKE_ASM_FLAGS


  SyntaxError: Non-UTF-8 code starting with '\x90' in file C:\Dev\masm\msys64\mingw64\bin\a2x.exe on line 1, but no encoding declared; see https://peps.python.org/pep-0263/ for details
  make[2]: *** [CMakeFiles/manpages.dir/build.make:74: cjxl.1] Error 1
  make[2]: *** Waiting for unfinished jobs....
  SyntaxError: Non-UTF-8 code starting with '\x90' in file C:\Dev\masm\msys64\mingw64\bin\a2x.exe on line 1, but no encoding declared; see https://peps.python.org/pep-0263/ for details
  make[2]: *** [CMakeFiles/manpages.dir/build.make:78: djxl.1] Error 1
  make[1]: *** [CMakeFiles/Makefile2:292: CMakeFiles/manpages.dir/all] Error 2
  make[1]: *** Waiting for unfinished jobs....
  C:/Dev/masm/msys64/opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/libjxl-src-0.7.6/submodules/libjxl/lib/jxl/dec_external_image.cc: In function 'jxl::Status jxl::{anonymous}::ConvertChannelsToExternal(const jxl::ImageF**, size_t, size_t, bool, JxlEndianness, size_t, jxl::ThreadPool*, void*, size_t, const jxl::PixelCallback&, jxl::Orientation)':
  C:/Dev/masm/msys64/opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/libjxl-src-0.7.6/submodules/libjxl/lib/jxl/dec_external_image.cc:290:21: warning: storing the address of local variable 'temp_channels' in '*channels.31_20 + _15' [-Wdangling-pointer=]
    290 |         channels[c] = &(temp_channels[c]);
        |         ~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~
  C:/Dev/masm/msys64/opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/libjxl-src-0.7.6/submodules/libjxl/lib/jxl/dec_external_image.cc:284:10: note: 'temp_channels' declared here
    284 |   ImageF temp_channels[kConvertMaxChannels];
        |          ^~~~~~~~~~~~~
  C:/Dev/masm/msys64/opt/cargo/registry/src/index.crates.io-6f17d22bba15001f/libjxl-src-0.7.6/submodules/libjxl/lib/jxl/dec_external_image.cc:246:48: note: 'channels' declared here
    246 | Status ConvertChannelsToExternal(const ImageF* channels[], size_t num_channels,
        |                                  ~~~~~~~~~~~~~~^~~~~~~~~~
  make: *** [Makefile:146: all] Error 2
  thread 'main' panicked at '
  command did not execute successfully, got: exit code: 2

  build script failed, must exit now', C:/Dev/masm/msys64/opt/cargo\registry\src\index.crates.io-6f17d22bba15001f\cmake-0.1.48\src\lib.rs:975:5
  note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

Back/forward buttons should open .jxl files.

Attempting to register the DLL causes an error. Windows says that it "failed to load." See the below screenshot for more info.

I followed the installation steps as described by downloading the DLL, opening PowerShell as an administrator, moving the DLL to my Downloads folder, and inputting cd C:\Users\[username]\Downloads and regsvr32 jxl_winthumb.dll into PowerShell.

This error shouldn't occur to my knowledge, and my laptop should start being able to start loading thumbnails for JXLs.

I've attempted this on three different Windows installations, and two of them run into this issue. The first attempt was on an Acer Nitro 5 (AN515-54) running Windows 10 Home, and has v0.1.7 registered. It works as expected. The second attempt was v0.1.10 on a HP Pavilion x360 Convertible (14m-dh0xxx) running Windows 10 Enterprise LTSC March 2019. It did not work and ran into the error described above. The third attempt was v0.1.10 on the same HP convertible, running Windows 10 Enterprise. It did not work and ran into the error described above.

Troubleshooting I tried:

• Tried to register v0.1.7 on the HP
• Tried registering the DLL in different folders, including System32 and SysWOW64
• Tried using Admin Command Prompt instead of Admin PowerShell
• Updated the HP to the latest software and drivers, including optional features
• Tried registering with and without "HEIF Image Extensions," "Web Media Extensions," and "Webp Image Extensions" installed on the Enterprise installation
• Turned the HP off and on

If there are dependencies that are actually missing, I'm at a loss for what they could be. Though, I'm glad the DLL works on one of my laptops and I do find it useful.

Tested in Windows Explorer and Directory Opus
OS: Windows 10 Pro 64bit
JXL-Winthumb version: v0.1.9
JXL version: 0.3.7
JXL settings used: "X:\ProgramFiles\JpegXL\cjxl.exe" {filepath} -d 2 -s 7 -j {filepath$|noext}_(JPEGXL_d2_s7).jxl

Horrifying result:

Expected result:
Well, definitely NOT what you see above on the right.

Original Image:

Converted to JXL:
IMG_20210704_184031 - Copy_(JPEGXL_d2_s7)_jxl.zip

Not sure what software supports this, though.

It's still using older one.

It turns out that Windows Photo Viewer still "exists", but not as a separate app.

This is what happens with flif_windows_plugin on Windows 10 21H1 19043.867:

So WIC support will be useful for a while, but no guarantee that this will keep being alive for future Windows versions.

... and ulimately split it out as a separate library for other codecs.

Nobody outside Microsoft knows its future but it seems it can still be useful, as Windows Photo Gallery still exists as a legacy-like component inside Windows.

I hoped browsers implementations could fulfill the need for viewers, but sadly that's not expected to happen soon.