Plan to support HDR images (.hdr, .exr) #816
Replies: 4 comments 12 replies
-
ktx doesn't pass files to the ASTC encoder though so the fact the encoder has a file reader for .hdr should not factor into a decision to support it or not. The author of the Radiance (.hdr) format (Greg Ward) points out the following shortcomings in this document: "Firstly, the dynamic range is much more than anyone else could ever utilize as a color representation. ... Another problem is that any RGB representation restricted to a positive range, such as RGBE and Pixar’s Log format, cannot cover the visible gamut using any set of “real” primaries. ... Finally, the distribution of error is not perceptually uniform with this encoding. In particular, step sizes may become visible in saturated blue and magenta regions where the green mantissa drops below 20." Currently ktx supports EXR via TinyEXR for creating floating point textures but reportedly "EXR supports too many compression formats so it's not interchangeable in practice. ... TinyEXR can only read a fraction of the .EXR files used in the wild, because many .EXR images utilize compression methods it doesn't support." It seems both formats have limitations. One question for @wasimabbas-arm, how many bits of precision does ASTC HDR support? If greater than 8 then .hdr will not allow achieving the best results for the format. @lexaknyazev would love to hear your opinion as the primary author of the ktx tool suite specification on whether the suite should support .hdr input. |
Beta Was this translation helpful? Give feedback.
-
How many bits of effective precision a lossy format supports is a bit of a hard question to answer. Notionally ASTC decompresses to an fp16 intermediate (or RGB9e5 if using decode_mode), BUT the actual precision in the compressed data will be lower than that due to the encoding. The actual dynamic range, and precision density within that used range, depends on the data you are compressing and will vary on a per block basis.
Isn't that a judgement call the user is qualified to make? It's their content pipeline, and they are already making other such judgement calls that impact image quality such as compression level.
Many uses of float textures in graphics are not storing color.
ASTC only supports encoding positive values in either case. (BC6H can do signed). The only possible interpretation of float data in the graphics API is linear sampling. There is no built-in OETF for sampling a non-linear gamut or a specific set of primaries; the user would have to provide that in shader code if they cared. (The only non-linear OETF in the API is sRGB, which is explicitly LDR).
As above, this assumes in the input data is color. For PBR it often isn't. My personal opinion on this one is that the choice of image formats is highly likely to be determined by the asset creation pipeline before encoding for GPU consumption happens, and changing that is often not trivial. KTX should just give users tools that can handle as much of the input content space as possible, and let them make the judgement call on what is an acceptable image quality for their use case. |
Beta Was this translation helpful? Give feedback.
-
what i use now are gainmaps and Ultra HDR https://github.com/MONOGRID/gainmap-js there are some plans to include this in jpg and imagemagic ImageMagick/ImageMagick#6377 with https://github.com/google/libultrahdr |
Beta Was this translation helpful? Give feedback.
-
We should look at UltraHDR (JPEG-R). I'm guessing this is the format read by the libultrahdr link provided by @arpu. I don't know if this is being proposed to ISO or if it is just an Adobe, Android thing. |
Beta Was this translation helpful? Give feedback.
-
ASTC encoder supports both .exr and .hdr formats. It will be nice that ktx can load these and then forward to encoders like ASTC encoder. Possibly true for basisu as well.
Beta Was this translation helpful? Give feedback.
All reactions