pfstmo_mantiuk06 error: incorrect saturation factor, accepted range is (0..1)

[Darxus]

I tone mapped an image in qtpfsgui using Mantiuk 06, and then
attempted to create a .exr of it using pfstools (since qtpfsgui
doesn't do hdr output) with the same values, and got this error:

pfstmo_mantiuk06 error: incorrect saturation factor, accepted range is
(0..1)

I disabled the limit in the source, recompiled, and was able to
generate the exr without problems. Why does this limit exist? Can it
be removed?

Ubuntu Jaunty package with the limits I found quickly removed:
Warning: this may be a BAD thing.
http://www.chaosreigns.com/hdr/pfstmo_1.1-1_i386.deb

It looks like these limits were specified in the papers that defined
the tone mapping algorithms. But I think you should allow violating
them. Either just document the limit in the man pages, or maybe add a
--violate-the-algorithm flag or something.


I'm thinking about creating a gui that, for a given algorithm,
generates images at both ends of all of the parameters, and then lets
you use sliders to adjust weighted averaging between them. I think
that should give an effect similar to re-rendering with any value,
with a much faster interface? Or do they do non-linear stuff with
those inputs?


$ pfsin StLouisArchMultExpHDR.exr | pfstmo_mantiuk06 --equalize-
contrast --saturation 8 | pfsout StLouisArchMultExpToneMappedSat8.exr
pfsoutexr warning: Some pixels exceed maximum value that can be stored
in an OpenEXR file (maximum value of HALF-16 float) and will be
clamped to that maximum. Use --fix-halfmax switch to rescale the data
to the valid range.

Mmm, blown saturation. Works though.

[rafm]

Hi,

On Aug 30, 4:31 am, Darxus <dar...@gmail.com> wrote:
> I tone mapped an image in qtpfsgui using Mantiuk 06, and then
> attempted to create a .exr of it using pfstools (since qtpfsgui
> doesn't do hdr output) with the same values, and got this error:
>
> pfstmo_mantiuk06 error: incorrect saturation factor, accepted range is
> (0..1)
>
> I disabled the limit in the source, recompiled, and was able to
> generate the exr without problems.  Why does this limit exist?  Can it
> be removed?

There is no specific reason for limiting this parameter besides
getting over-saturated images. If it is set too high, most colors will
run out of gamut.

The reason for limiting the range of parameter values is to ensure
that the resulting images look acceptable.

I extended the range of this parameter to 0 - 2 (for mantiuk06
operator).

> I'm thinking about creating a gui that, for a given algorithm,
> generates images at both ends of all of the parameters, and then lets
> you use sliders to adjust weighted averaging between them.  I think
> that should give an effect similar to re-rendering with any value,
> with a much faster interface?  Or do they do non-linear stuff with
> those inputs?

Some parameters are linear, some are not, so you will not get exactly
the same output. This, however, may for fine for preview.

Cheers,

Rafal