Process HDRI without clamping

[roelandsch]

Hi all,

I am trying to process an HDRI image. But in the end when writing the EXR image the values are always clamped to [0.0–1.0]. For example:

Code: Select all

convert -size 100x100 gradient: gradient1.exr
convert -size 100x100 gradient: -level 0,25% gradient2.exr

gradient1.exr will contain a gradient ranging from 0 to 1. gradient2.exr will be clamped. Is there a way to make it contain a gradient ranging from 0 to 4?

In 3D rendering HDR images are often used to define illumination from the environment. They will almost always contain large values where the sun or light sources are, and clamping these images will make them useless.

--
Roeland

[fmw42]

IM only deals with 16-bit float (half-mode) EXR images (via OpenEXR delegate), to my knowledge.

see
http://www.openexr.com/index.html

In order to keep the floats, you will need to compile IM in Q16 HDRI mode.

[roelandsch]

Hi,

I did more testing in the meantime, only certain operators will clamp highlights. I'll describe in more detail what I've done so far:

I have downloaded the ImageMagick and OpenEXR source code, and I have made a build for 64-bit Windows with HDRI support, and with the EXR delegate. This is the output of identify -version:

Code: Select all

Version: ImageMagick 6.8.9-8 Q16 x64 2014-08-26 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2014 ImageMagick Studio LLC
Features: DPC HDRI Modules OpenMP
Delegates: bzlib cairo freetype jbig jng jp2 jpeg lcms lqr openexr pangocairo png ps rsvg tiff webp xml zlib

The following command works as expected. It will as expected create a smaller version of environment.exr, and it will preserve the highlights:

Code: Select all

convert environment.exr -resize 50% environment_small.exr

Using the +level operator will also preserve highlights.

Code: Select all

convert environment.exr +level 0,200% environment_bright.exr

However, the -level operator will clip highlights. -level 0,100% has the same effect as -clamp. Is this intended?

Code: Select all

convert environment.exr -level 0,50% environment_bright.exr

--
Roeland

[snibgo]

v6.8.9-6 Q32 HDRI compiled under Cygwin on Windows 8.1.

I confirm that "-level" clips but "+level" doesn't. For example:

Code: Select all

F:\web\im>%IMDEV%convert -size 1x5 gradient: -level 0,50% txt:
# ImageMagick pixel enumeration: 1,5,4294967295,srgb
0,0: (100%,100%,100%)  #FFFFFFFFFFFFFFFFFFFFFFFF  white
0,1: (100%,100%,100%)  #FFFFFFFFFFFFFFFFFFFFFFFF  white
0,2: (100%,100%,100%)  #FFFFFFFFFFFFFFFFFFFFFFFF  white
0,3: (50%,50%,50%)  #800000008000000080000000  srgb(50%,50%,50%)
0,4: (0%,0%,0%)  #000000000000000000000000  black

F:\web\im>%IMDEV%convert -size 1x5 gradient: +level 0,200% txt:
# ImageMagick pixel enumeration: 1,5,4294967295,srgb
0,0: (200%,200%,200%)  #FFFFFFFFFFFFFFFFFFFFFFFF  srgb(200%,200%,200%)
0,1: (150%,150%,150%)  #FFFFFFFFFFFFFFFFFFFFFFFF  srgb(150%,150%,150%)
0,2: (100%,100%,100%)  #FFFFFFFFFFFFFFFFFFFFFFFF  white
0,3: (50%,50%,50%)  #800000008000000080000000  srgb(50%,50%,50%)
0,4: (0%,0%,0%)  #000000000000000000000000  black

I can't find what code causes this clipping. I suggest it is a bug (rather than a feature).

EDIT: For any "-level", there is a "+level" that gives the same result aside from clipping. Hence a workaround is to use the equivalent "+level".

[roelandsch]

I see, thanks.

--
Roeland

[fmw42]

I do not think this is a bug.

The purpose of -level 0xY% is to stretch Y% to 100% (white).

The purpose of +level 0xY% is to stretch 100% (white) to Y%.

[snibgo]

Those purposes are fine. They don't say what should happen when the input to "-level" is above Y%. Should it be white, or above white? Clipping would be consistent with those purposes, and not clipping would also be consistent.

I can't see any good reason for "-level" clipping.

The operators "-evaluate", "-gamma" and "-modulate" don't clip.

If any operators clip in HDRI (and we want them to clip), this should be documented on http://www.imagemagick.org/script/comma ... ptions.php , or somewhere.

[fmw42]

OK, I see your point.

In non-hdri mode, clipping is important because values of Y% less than 100% is pushed to 100% and since there may be larger values in the image, it would need to be clipped.

If Y%=50%, then midgray goes to white. One would then expect 100% to go to 200% in HDRI mode, but be clipped to 100% in non-hdri mode.

I suspect this was not considered for HDRI and it so it clips.

I expect +level clipping was not performed, because its typical use would have been to make 100% (white) go to Y% where Y<=100. Thus clipping was left off. But in HDRI mode if you specify (typically unexpected values like) 200% for Y% it won't clip because it was not considered relevant for non-hdri mode.

So I think this issue was just an oversight for HDRI mode. But should be fixed to remove clipping for -level in HDRI mode.