JPEG lossless transcoding resulting JXL images without exif metadata about libjxl HOT 14 CLOSED

You should be able to disable metadata compression in cjxl with --compress_boxes=0 also I think the reason you are getting the error about Brotli in ExifTool despite having Brotli installed is because ExifTool requires a Perl module/wrapper to interface/communicate with Brotli although I can't really help any further with that as I am not experienced enough to know the steps required to properly set that up.

from libjxl.

The version of ExifTool you are using is likely the cause since JXL support was improved in version 12.63 however you are using version 12.60 which lacks the improved support for reading JXL files.
https://exiftool.org/history.html

from libjxl.

Thanks @goodusername123 . How do I disable brotli for metadata compression? After upgrading to exiftool 12.64, I got

ExifTool Version Number         : 12.64
File Name                       : DSCF0170.jxl
Directory                       : .
File Size                       : 2.5 MB
File Modification Date/Time     : 2023:07:11 02:19:07-07:00
File Access Date/Time           : 2023:07:15 15:02:22-07:00
File Inode Change Date/Time     : 2023:07:15 15:02:17-07:00
File Permissions                : -rw-r--r--
File Type                       : JXL
File Type Extension             : jxl
MIME Type                       : image/jxl
Major Brand                     : JPEG XL Image (.JXL)
Minor Version                   : 0.0.0
Compatible Brands               : jxl
Image Width                     : 2848
Image Height                    : 2136
Warning                         : Install IO::Uncompress::Brotli to decode Brotli-compressed metadata
Image Size                      : 2848x2136
Megapixels                      : 6.1

But I have brotli installed in my system

==> brotli: stable 1.0.9 (bottled), HEAD
Generic-purpose lossless compression algorithm by Google

from libjxl.

With sudo perl -MCPAN -e 'install IO::Uncompress::Brotli', I can confirm that exiftool 12.64 can properly read brotli compressed exif.

Look like in MacOSX Sonoma Public Beta, the Preview is not able to read exif for both uncompressed or compressed exif. The image looks correct though.

from libjxl.

Note that exiv2 should support brotli compressed boxes since version 0.28 as well.

from libjxl.

See also / Duplicate of: #1911

from libjxl.

I can confirm that exiftool 12.64 and exiv2 0.28 reads exif metadata, however some apps that use exiv2 like gThumb still don't show it. Also, there are more problems with ICC embedded profiles, like this:

[quantum@parsec q]$ exiv2 --extract C QC014636.JXL 
No embedded iccProfile: QC014636.JXL
[quantum@parsec Image-ExifTool-12.64]$ ./exiftool -icc_profile -b -w icc QC014636.JXL 
    0 output files created
[quantum@parsec q]$ jxlinfo QC014636.JXL 
JPEG XL file format container (ISO/IEC 18181-2)
JPEG XL image, 4416x2944, (possibly) lossless, 8-bit RGB
Color space: 560-byte ICC profile, CMM type: "ADBE", color space: "RGB ", rendering intent: 0
JPEG bitstream reconstruction data available
Brotli-compressed Exif metadata: 11939 compressed bytes
Brotli-compressed xml  metadata: 235 compressed bytes
[quantum@parsec q]$ 

from libjxl.

however some apps that use exiv2 like gThumb still don't show it

They're probably still linked against the 0.27.x (or older) version, or the distributed 0.28.x version could be built w/o brotli support...

from libjxl.

This seems not to be the case, because

• I'm using stable Manjaro and exiv2 0.28 is the only one available and required by pix/gThumb
• it doesn't have any problems reading exif using command line, so it is probably built with brotli support.
• darktable seems to be using the same exiv2 and shows exif correctly

from libjxl.

Re embedded ICC profile: it is stored in the actual codestream and not as metadata (there are pros and cons to this choice obviously). Neither Exiv2 nor exiftool currently decode the codestream AFIAK. See e.g. Exiv2/exiv2#1506 and exiftool/exiftool#157

from libjxl.

Re embedded ICC profile: it is stored in the actual code stream and not as metadata. Neither Exiv2 nor exiftool decode the codestream AFIAK. See e.g. Exiv2/exiv2#1506 and exiftool/exiftool#157

Yes, this is what I also suspect (and exiftool explicity states that it has no ICC support).
However there are more mysteries regarding ICC and JXL:

• gThumb and GIMP can read ICC profile from lossless JPG conversion, but not from vardct JXL file.
• JXL has currently no support for AdobeRGB color space in vardct mode (gamut cropped to sRGB and invalid transfer function used), but works ok with lossless AdobeRGB JPGs.

from libjxl.

Sure, but color management has nothing to do w/ metadata parsing. Those apps access ICC directly via libjxl.

Re Adobe RGB, when you decode lossy as float, even though the resulting color space is "unexpected" the data is not lost/clipped, and the app can still recover everything to whatever color space it wants, provided it does color management right. Try darktable for example.

from libjxl.

Sure, but color management has nothing to do w/ metadata parsing. Those apps access ICC directly via libjxl.

Re Adobe RGB, when you decode lossy as float, even though the resulting color space is "unexpected" the data is not lost/clipped, and the app can still recover everything to whatever color space it wants, provided it does color management right. Try darktable for example.

No, the vardct AdobeRGB image is not displayed correctly by Darktable and Eye Of Gnome either. The wide gamut information is lost. This is becasue even if you encode and decode AdobeRGB image using cjxl and djxl, you will get RGB_D65_SRG_Rel_Lin colorspace (unless overridden by color space argument). All the wide gamut data is in JXL file but is lost on decode.

Because AdobeRGB doesn't use linear transfer function nor sRGB color primaries. The decoded image is incorrect, using color management to solve the issue is not a proper way of dealing with it.

from libjxl.

Closing this as I confirm that the brotli compressed metadata can be read from newer version of exiftools.

from libjxl.