HDR data not presented as floating point values

[Jazzdoodle]

ImageMagick offers the ability to read HDR image data and return float arrays with high dynamic range. Unfortunately, loading an HDR file with ImageMagick.jl, I only receive a 16-bit-quantized representation with clamped values. The specific format I tried, Radiance RGBE, supports color values with a shared exponent of up to 255, so the dynamic range is significantly higher than what 16 bit or even 32 bit integers offer. This format is of particular importance for high dynamic range environments used for physically based rendering.

This may be an issue with how the ImageMagick library was built, as there is an option to turn off proper HDR handling and use 16 bit instead. See ImageMagick HDR for details.

But even if that is the origin of the problem, the Julia wrapper does not even consider floating point representations as a possible outcome. The code only refers to 8, 16 or 32 bit integers as valid pixel depths.

Having this fixed would be great help for our Julia realistic rendering engine.

[timholy]

A PR fixing this would be welcome!

[tlnagy]

I've recently written a pure-Julia TIFF parsing package (https://github.com/tlnagy/TIFF.jl) that can handle HDR images and returns Gray{Float} or RGB{Float} images.

It's technically a WIP, but it would be great to have some feedback.

[timholy]

From a quick glance it looks amazing. I am not an expert on TIFF (far from it), so I only have generic comments. (Is there a way to use GitHub commenting features on an existing repo?)

• add @inbounds to reversebits!, read!? (look like performance hotspots)
• consider maybe_bswap! instead of do_bswap? (Note in particular the addition of !)

[tlnagy]

I just did a major refactor of the internals (https://github.com/tlnagy/TIFF.jl/commit/5804882bb1d6d2b9be1d768ec3cbfb1c10d606a2) and do_bswap isn't needed any more. How much do you suspect @inbounds will help? My primary issue is with the memory usage of views especially here: https://github.com/tlnagy/TIFF.jl/blob/5804882bb1d6d2b9be1d768ec3cbfb1c10d606a2/src/compression.jl#L20 it doesn't seem to be elided and leads to much higher memory usage than ImageMagick (see coffee.tif example below).

benchmarking data I've been extremely unsatisfied with the access speed so I'm probably going to rebuild the loading sequence such that the lazy transformations are realized before the image is returned to the user. See https://github.com/tlnagy/TIFF.jl/issues/4

We can continue this discussion over TIFF.jl so we don't totally hijack this thread.

EDIT: I should also note in fairness, access ops will be slower with TIFF.jl due to the lazy transformations.

[tlnagy]

Also, @timholy I appreciate you taking the time to look at it! I've learned a ton from all your great packages, I owe a large part of my Julia-fu to them.

[timholy]

Thanks @tlnagy! Really appreciate your steady efforts to improve our TIFF loading!

[tlnagy]

Just a heads up, I now eagerly evaluate the final product so the drawback of the lazy evaluations is gone in TIFF.jl while support for HDR images should still there! I keep a lot of the speed improvements too:

Load benchmarking: TIFF.jl#10 PR vs ImageMagick.jl v1.1.6

load time (lower is better)	memory usage during load (lower is better)

[kimikage]

While not a direct solution to this issue, I am attempting to handle the Radiance RGBE format directly.

The plan started around 2021 but was suspended due to my personal reasons. The development has not progressed since that time, and basic functionality has not yet been implemented. (~In particular, plain RGB cannot yet be encoded into RGBE.~ Edit: implemented but not fully tested.) However, I decided to open the repositories involved to the public. https://github.com/kimikage/HDRColorTypes.jl https://github.com/kimikage/HDRImages.jl

cf. https://discourse.julialang.org/t/pre-rfc-ann-color-related-packages-yuvcolortypes-cmykcolortypes-colorprofiles-hdrcolortypes-hdrimages/113032/