JPEG XL

EXR -> JXL Encoding

gb82

2024-02-19 01:37:53
2024-02-19 01:37:53	I'm gonna send some samples and explain my problem...
2024-02-19 01:39:04	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]`
2024-02-19 01:39:44	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
2024-02-19 01:40:22	but on some image viewers, the jxl images look exactly the same, which intrigues me because the from_exr jxl is so much smaller...
2024-02-19 01:41:02	here's an example of the EXR -> JXL in GNOME's older image viewer, where I'm assuming it was interpreted correctly. Now...
2024-02-19 01:41:32	new image viewer (Loupe) will display the same behavior as Thorium, Waterfox, etc. Which is doing it correctly in this case?

190n

2024-02-19 01:52:04

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

gb82

2024-02-19 02:13:20	from_exr & from_png are not visually identical, is the 16-bit int vs float making that much of a difference?
2024-02-19 02:13:35	also weird that the metadata didn't transfer to from_exr

190n

2024-02-19 02:14:10

oh wait the colorspaces are also slightly different

Quackdoc

2024-02-19 02:14:26	png is wrong
2024-02-19 02:14:30	well "wrong"

190n

2024-02-19 02:14:39

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

Quackdoc

2024-02-19 02:15:18	in the first place, this looks like an EXR that needs to be rendered with an sRGB transfer
2024-02-19 02:15:22	its weird image

gb82

2024-02-19 02:16:51

i just exported from darktable without messing with anything

Quackdoc

2024-02-19 02:23:31	well darktable is being stupid then
2024-02-19 02:23:43	it's a bad file
2024-02-19 02:24:26	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" ```
2024-02-19 02:25:06	so while the PNG is "accurate to your intent" perhaps, the file itself is actually outright bad
2024-02-19 02:26:49	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`
2024-02-19 02:27:01	ofc since discord cant handle png metadata you need to open open it
2024-02-19 02:28:04	so yeah, cjxl is correctly encoding the file, darktable just being dumb as usual
2024-02-19 02:29:50	for more info you can start here https://openexr.com/en/latest/TechnicalIntroduction.html?highlight=gamma#what-s-in-the-numbers
2024-02-19 02:36:44	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
2024-02-19 02:38:08	(preview images on the otherhand are always gamma2.2 encoded)

gb82

2024-02-19 02:42:00	the png is the problematic file?? weird...
2024-02-19 02:42:53	what package is `iconvert` part of?
2024-02-19 02:43:02	or is it just magick's convert?

Quackdoc

2024-02-19 02:51:46	oiio
2024-02-19 02:52:03	only if the png was generated from the exr

gb82

2024-02-19 02:53:18	no it was output from Darktable directly
2024-02-19 02:53:28	what exactly is wrong with it?

Quackdoc

2024-02-19 02:56:50

oh then its fine

gb82

2024-02-19 03:01:23

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

Quackdoc

2024-02-19 03:02:19	output to png
2024-02-19 03:02:30	dark table clearly cant handle exr right lol

gb82

2024-02-19 03:15:58

gotcha

spider-mario

2024-02-19 07:44:08	from what I recall, it does if you select the proper colorspace on export
2024-02-19 07:44:40	and I think it only skips writing the chromaticities if it's Rec. 709

gb82

2024-02-21 08:12:04

🤔 hm

spider-mario

2024-02-21 10:11:54

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

gb82

2024-02-27 11:00:14

oh, interesting, thanks

Info

JPEG XL

General chat

Voice Channels

Archived

EXR -> JXL Encoding