Unexpected precision loss through conversion to half-float when writing an image.

[ahemberger]

Hi;

I'm trying to use colour-science to shift the values of some HDR images generated with ptgui to a range that's easily-viewable. I notice when I do this, though, that there seems to be a pretty big data loss in transit; my input files are on the order if 280MB, whereas my output files are around 85MB.

Here is what I'm doing:

        aces = colour.models.RGB_COLOURSPACE_ACESCG
        aces_weights = aces.matrix_RGB_to_XYZ[1]
        maximum_intensity = np.power(2.0, 16)

        # Read original image
        img_orig = colour.read_image(os.path.abspath(file))
        height, width, _ = img_orig.shape

        # compute the average luminance of the image
        # in ACESCG space.
        total_weighted_luminance = 0

        for y in range(height):    
            theta = (y / (height-1) * 2 - 1) * np.pi/2.0
            for x in range(width):
                pixel_luminance = img_orig[y, x].dot(aces_weights)
                # Do not factor in very bright values
                if pixel_luminance < maximum_intensity:
                    total_weighted_luminance += pixel_luminance * np.cos(theta)
    
        avg_weighted_luminance = total_weighted_luminance / (width * height)
        avg_weighted_luminance = 0.5 / avg_weighted_luminance 
        img_normalized =  img_orig * avg_weighted_luminance

        out_file = os.path.abspath(file)
        out_file = out_file.replace("orig", "normalized")
        colour.write_image(img_orig, img_normalized)

When I print the dtype of both images, the output says "float32". The images contain the sun on a bright clear day; the smaller output images have "inf" values in the core of the sun when I inspect the images in Nuke, whereas the original images have values that vary through the sun's core.

It feels as though I'm losing data, though the dtype parity seems to disprove this...unless I'm mistaken about what ptgui calls a float32 image and what colour/numpy calls a float32 image?

Might anyone have clues to offer?

Thanks!

[mileslauridsen]

@ahemberger sounds like you might be outputting the normalized HDRI as 16bit half? You'd get inf on any value over 65,536.

If you have Open Image IO run this to check values and dtype of the saved image. I'm guessing the dtype you're referencing is the internal dtype used in colour-hdri.

oiiotool -v --stats --info normalized.exr

[ahemberger]

Thank you for offering me a much better way of confirming this than trying to find out useful information about this image using Nuke/Natron/Photoshop on a macbook M1 max! (spoiler alert: none of those tools were helpful for this).

oiiotool reports that the output image is half float, while the input image is float. The docs suggest that one option I have could be specifying my output image thusly:

write_image(out, path, bit_depth='float64') # (docs say the default is 'float32')

but this doesn't actually seem to work:

Traceback (most recent call last):
  File "/Applications/Houdini/Houdini19.0.622/Frameworks/Python.framework/Versions/3.7/lib/python3.7/site-packages/imageio/plugins/_freeimage.py", line 828, in allocate
    fi_type = FI_TYPES.fi_types[(dtype.type, n_channels)]
KeyError: (<class 'numpy.float64'>, 3)

I would love to better understand what's actually going on here.

[ahemberger]

A clue I just discovered: if I write out a tiff or hdr file, I get full precision and unclipped values.

I am doing all this on a Mac M1 MAX, which has been a horrific pain to deal with when it comes to trying to align the best of python, exr libraries, colour, numpy, oiio, etc. I suspect the culprit here is somewhere in freeimage, rather than colour itself.

[KelSolaar]

Hi,

Yes, it is certainly a freeimage related issue here! I can take a look over the weekend.

Cheers,

Thomas

[KelSolaar]

Allright, so it is actually easy and probably something we should document. If the backend is Freeimage because you haven't installed OpenImageIO, you need to pass a flags kwarg to modify the Freeimage options. They are documented there:

https://github.com/leapmotion/FreeImage/blob/5ad4a85f54957f430f64659d6e12d191b16ac058/Wrapper/FreeImage.NET/cs/Library/Enumerations/FREE_IMAGE_SAVE_FLAGS.cs#L36

This works:

import colour
a = colour.utilities.full([8, 4, 3], 100000)
colour.write_image(a, "/Users/KelSolaar/Downloads/Test.exr", flags=0x0001)

[ahemberger]

Amazing! 1) I would have NEVER discovered this, and 2) this is excellent motivation for me to figure out how to get oiio up and running for myself :)

Thank you all so very much!

[KelSolaar]

I updated the colour.write_image (and the underlying colour.io.write_image_Imageio) definition in develop so that this should work out of the box as a function of the bit-depth of the data passed.