Ubuntu 24.04 LTS Won't Support JPEG-XL Out-Of-The-Box

[Quackdoc]

If you compress AdobeRGB JPEG image (even with embedded AdobeRGB ICC profile, usually profile is not attached by a camera, but can be added with exif tools) using:



You will end up with file that has no color management in gimp and gThumb, and looks flat (exactly like AdobeRGB image showed as plain sRGB in non color managed apps). But in Darktable it's OK.

When decoded using djxl, the embedded AdobeRGB ICC color profile will be back in decoded image, although recreated as "D65 blahblabh", but technically probably equivalent to AdobeRGB (didn't checked the rest of params, white point is correct and image displays correctly, including colors outside sRGB space). It would be nicer to have "AdobeRGB (compatible)" shown there, though.

yeah I already made an issue regarding AdobeRGB compatible part. https://github.com/libjxl/libjxl/issues/2725

Ill try out the issue with adobeRGB tonight if I can for sure. I use neither gthumbs nor gimp, but can easily download.

EDIT: Just tested gwenview and loupe both them work right, so I would for sure assume something is wrong with gimp/gthumb

[sobrus]

EDIT: Just tested gwenview and loupe both them work right, so I would for sure assume something is wrong with gimp/gthumb

I've just tested loupe, and whlle it does indeed displayed the image correctly color-wise, the gamma seems to be different (dark parts of image are darker in loupe than in gThumb with AdobeRGB profile applied, contrast seem stronger). Original JPG+ICC image viewed in loupe is also affected this way, so this is either a problem with Loupe - or Loupe is the only app displaying gamma correctly, even for JPG files.

Darktable works correctly with JXL, showing correct colors and full exif right from JXL file. Darktable gamma is same as in gThumb.
So I'm assuming something is wrong with Loupe.
btw. Loupe is not able to read exif from jxl, just like gThumb.

edit: I've removed part regarding gamma in jxl file, it was my mistake

[Sonadow]

I wish Canon, Nikon, Fuji, Sony, or (lol) Pentax would create a camera with JPEG-XL support. It'd be a real game changer with digital photography and digital cameras adopting the format would really pressure everyone else into adopting it.

Dream on. None of them have any reason or incentive to adopt JPEG-XL when smartphones drove the compact and prosumer camera segments to outright extinction.

And no sane photographer will shoot in JPEG on a DSLR or MIL, especially a fullframe.

[Quackdoc]

I've just tested loupe, and whlle it does indeed displayed the image correctly color-wise, the gamma seems to be different (dark parts of image are darker in loupe than in gThumb with AdobeRGB profile applied, contrast seem stronger). Original JPG+ICC image viewed in loupe is also affected this way, so this is either a problem with Loupe - or Loupe is the only app displaying gamma correctly, even for JPG files.

Darktable works correctly with JXL, showing correct colors and full exif right from JXL file. Darktable gamma is same as in gThumb.
So I'm assuming something is wrong with Loupe.
btw. Loupe is not able to read exif from jxl, just like gThumb.

edit: I've removed part regarding gamma in jxl file, it was my mistake

the darkness is an issue with sRGB in general, sRGB can be interpreted/Displayed 2 ways (even if this isn't accurate) either with an sRGB transfer or a pure 2.2 transfer. and ofc especially on linux, the chances that you are going to need to map the transfer, regardless of what transfer, is fairly high. So I honestly can't say if you are dealing with is an issue with loupe, or just the retarded 2.2 vs sRGB issue we have always dealt with.

Lately more linux focused apps seem to shifting to a "Interpet sRGB as sRGB but display as Gamma2.2", I believe KDE is now doing this too. It's possible that loupe is just outright doing something wrong, or jxl-oxide is. (jxl-oxide can handle mapping to various transfers/gamuts now as stated but its up to the implementation to decide how this is done).

I'll try and look into the loupe issue later, but I've made known the issue about gthumb and gimp. for investigation

[skeevy420]

Dream on. None of them have any reason or incentive to adopt JPEG-XL when smartphones drove the compact and prosumer camera segments to outright extinction.

And no sane photographer will shoot in JPEG on a DSLR or MIL, especially a fullframe.

Amateurs would. Professionals wouldn't outside of specific situations (like needing the extra few shots for burst). Most amateurs I know are happy with JPEG, some auto or P mode, and a kit zoom. They ain't pixel peepers. What the Pros would do is shoot in lossless JXL since it takes less space than a RAW and then they may or may not export that as a lossy JXL for distribution. Ideally, both the camera and smartphone would have a dedicated JXL chip to use higher JXL effort levels as to not impede burst shooting speed, for lossy/lossless conversions, and hopefully energy savings.

This is one of those circular dependencies. Camera/phone/etc makers aren't adopting it because the software ecosystem for JXL doesn't come close to what the current status quo is capable of and the software ecosystem is taking its time adopting JXL because hardly any hardware actually uses it. The Chrome platform pulling their support of it really isn't helping anything and is probably the biggest blocker to anyone else wanting to use it. Why use a CODEC that the internet doesn't support? That's just stupid.

I often wonder if it being royalty free is why no one is adopting it. Why adopt a format where everyone else can benefit off of what you do when you can create a format that's potentially better that you can charge others to use? It makes horribly good sense.

[Quackdoc]

the darkness is an issue with sRGB in general, sRGB can be interpreted/Displayed 2 ways (even if this isn't accurate) either with an sRGB transfer or a pure 2.2 transfer. and ofc especially on linux, the chances that you are going to need to map the transfer, regardless of what transfer, is fairly high. So I honestly can't say if you are dealing with is an issue with loupe, or just the retarded 2.2 vs sRGB issue we have always dealt with.

Lately more linux focused apps seem to shifting to a "Interpet sRGB as sRGB but display as Gamma2.2", I believe KDE is now doing this too. It's possible that loupe is just outright doing something wrong, or jxl-oxide is. (jxl-oxide can handle mapping to various transfers/gamuts now as stated but its up to the implementation to decide how this is done).

I'll try and look into the loupe issue later, but I've made known the issue about gthumb and gimp. for investigation

<quotting unapproved>
sobrus