JPEG XL

I'm gonna send some samples and explain my problem...

here are some (very small) source images (labelled fullres) and the jxls encoded from them. settings: `cjxl fullres.exr from_exr.jxl -d 1.0 -e 9 -p -v` version: `cjxl v0.10.0 07203da0 [AVX2,SSE4,SSE2]`

the issue I'm having is that opening the from_exr.jxl in most image viewers, it looks washed out, presumably due to the gamma and EXR being for HDR and whatnot

but on *some* image viewers, the jxl images look exactly the same, which intrigues me because the from_exr jxl is so much smaller...

here's an example of the EXR -> JXL in GNOME's older image viewer, where I'm assuming it was interpreted correctly. Now...

new image viewer (Loupe) will display the same behavior as Thorium, Waterfox, etc. Which is doing it correctly in this case?

if jxlinfo is correct, `from_exr.jxl` is 16-bit float while `from_png.jxl` is just "16-bit RGB" (so i assume integer?), and the latter also has 22362 (exif) + 1556 (xml) bytes of compressed metadata

from_exr & from_png are not visually identical, is the 16-bit int vs float making that much of a difference?

also weird that the metadata didn't transfer to from_exr

oh wait the colorspaces are also slightly different

png is wrong

well "wrong"

from_exr uses linear transfer function and perceptual rendering intent, while from_png uses srgb transfer function and relative rendering intent

in the first place, this looks like an EXR that needs to be rendered with an sRGB transfer

its weird image

i just exported from darktable without messing with anything

well darktable is being stupid then

it's a bad file

notice something missing Yours: ```ps ➜ gb exrheader fullres.exr file fullres.exr: file format version: 2, flags 0x0 channels (type chlist): B, 32-bit floating-point, sampling 1 1, plinear G, 32-bit floating-point, sampling 1 1, plinear R, 32-bit floating-point, sampling 1 1, plinear comment (type string): "Created with darktable 4.6.1" compression (type compression): piz dataWindow (type box2i): (0 0) - (340 191) displayWindow (type box2i): (0 0) - (340 191) lineOrder (type lineOrder): increasing y pixelAspectRatio (type float): 1 screenWindowCenter (type v2f): (0 0) screenWindowWidth (type float): 1 ```test:```ps ➜ gb exrheader WideColorGamut.exr file WideColorGamut.exr: file format version: 2, flags 0x0 channels (type chlist): B, 16-bit floating-point, sampling 1 1 G, 16-bit floating-point, sampling 1 1 R, 16-bit floating-point, sampling 1 1 chromaticities (type chromaticities): red (0.64 0.33) green (0.3 0.6) blue (0.15 0.06) white (0.3127 0.329) compression (type compression): zip, multi-scanline blocks dataWindow (type box2i): (0 0) - (799 799) displayWindow (type box2i): (0 0) - (799 799) lineOrder (type lineOrder): increasing y pixelAspectRatio (type float): 1 screenWindowCenter (type v2f): (0 0) screenWindowWidth (type float): 1 type (type string): "scanlineimage" ```

so while the PNG is "accurate to your intent" perhaps, the file itself is actually outright bad

if you use inconvert which can correctly decode, but not encode, exr files you get the proper png and jxl `iconvert fullres.exr fullres-convert.png`

ofc since discord cant handle png metadata you need to open open it

so yeah, cjxl is correctly encoding the file, darktable just being dumb as usual

for more info you can start here https://openexr.com/en/latest/TechnicalIntroduction.html?highlight=gamma#what-s-in-the-numbers

what darktable is **supposed** to do, is save the image with no transfer function applied to the pixels (EXR is **always** linear), and store the chromatacity values, it did neither

(preview images on the otherhand are always gamma2.2 encoded)

the *png* is the problematic file?? weird...

what package is `iconvert` part of?

or is it just magick's convert?

oiio

only if the png was generated from the exr

no it was output from Darktable directly

what exactly is wrong with it?

oh then its fine

for the optimal output from Darktable, should I be outputting EXRs and converting to PNG, or just outputting PNG directly?

output to png

dark table clearly cant handle exr right lol

gotcha

from what I recall, it does if you select the proper colorspace on export

and I think it only skips writing the chromaticities if it's Rec. 709

🤔 hm

one of these “linear” options would be the one to choose when exporting to EXR

oh, interesting, thanks