whatever, it’s data. who am i to judge what people but inside their files. are you arguing the gui should not offer non-linear TRC here? i suppose i could issue a warning, that wouldn’t hurt.
Sure. Just saying most tools will assume EXR data is linear w/ Rec709 primaries (as that is in the spec), and/or that the user knows what they’re actually doing.
Might be an idea, dt does this already.
i sympathise with this approach. fwiw the spec has a standard attribute for chromaticities that vkdt writes and gimp ignores. there is no such standard attribute for TRC though. i still write one, just so you have a chance to remember from the metadata what you wrote in the file in the first place.
I wasn’t really talking about a TRC attribute, but the fact that the data stored in EXR is implicitly linear (and shouldn’t really be anything else - therefore no need for a TRC attribute from the point of view of the spec). The fallback/default for primaries is explicitly Rec709, and it is indeed unfortunate Gimp doesn’t support arbitrary chromaticities attribute…
Awesome, as it is supported in at least dt (it reads it and writes it as well), and probably other apps.
It clearly says linear was assumed by Gimp for EXR import.
From the OpenEXR Technical Introduction:
“We store linear values in the RGB 16-bit floating-point numbers. By this we mean that each value is linear relative to the amount of light in the depicted scene. This implies that display of images requires some processing to account for the non-linear response of a typical display. In its simplest form, this is a power function to perform gamma correction. There are many recent papers on the subject of tone mapping to represent the high dynamic range of light values on a display. By storing linear data in the file (double the number, double the light in the scene), we have the best starting point for these downstream algorithms. Also, most commercial renderers produce linear values (before gamma is applied to output to lower precision formats).”
There’s no TRC tag in the metadata. There is an optional chromaticities tag:
“The chromaticities attribute is optional, and many programs that write OpenEXR omit it. If a file doesn’t have a chromaticities attribute, display software should assume that the file’s primaries and the white point match Rec. ITU-R BT.709-3”
Without a way to communicate a TRC in the image file, the only way you can have a prayer that someone will interpret the image data correctly is to encode linear, and either omit the primaries/whitepoint or specify one that represents the color encoding.
yes, don’t do that says the rest here… use linear trc and sRGB primaries for exr output (if you want gimp and probably most other software) to pick it up out of the box.
The rest here is right.
Thank you all!
What this means is, .exr is not a good format for general distribution to non-colormanaged destinations. Unless you want to make a sub-hobby of answering “Why is my image so dark?” questions… 
2 Likes
Or, to put differently as mentioned above, it is a format for people in the know. 
I just tried to compile from source once again on my laptop (I think it used to work on its iGPU somewhat okay), but getting:
clang -Wall -pipe -I. -D_GNU_SOURCE -std=c11 -fPIC -Wall -pipe -O3 -march=native -DNDEBUG -c gui/gui.c -o gui/gui.o
clang -Wall -pipe -I. -D_GNU_SOURCE -std=c11 -fPIC -Wall -pipe -O3 -march=native -DNDEBUG -c gui/render.c -o gui/render.o
In file included from gui/render.c:3:
In file included from gui/nk.h:12:
gui/nuklear_glfw_vulkan.h:478:14: error: use of undeclared identifier 'gui_shd_gui_vert_spv'
478 | dev, gui_shd_gui_vert_spv,
| ^
gui/nuklear_glfw_vulkan.h:479:9: error: use of undeclared identifier 'gui_shd_gui_vert_spv_len'
479 | gui_shd_gui_vert_spv_len, VK_SHADER_STAGE_VERTEX_BIT);
| ^
gui/nuklear_glfw_vulkan.h:481:14: error: use of undeclared identifier 'gui_shd_gui_frag_spv'
481 | dev, gui_shd_gui_frag_spv,
| ^
gui/nuklear_glfw_vulkan.h:482:9: error: use of undeclared identifier 'gui_shd_gui_frag_spv_len'
482 | gui_shd_gui_frag_spv_len, VK_SHADER_STAGE_FRAGMENT_BIT);
| ^
4 errors generated.
make[2]: *** [Makefile:100: gui/render.o] Fehler 1
hm seems it didn’t build the gui shaders. do you have xxd installed? it comes with vim on some distros.
It complained about xxd missing on the first try. I installed something called tinyxxd, and got that error on second try. I now tried make -clean and now it seems to work (so far). Thanks 
1 Like