Re: [Openexr-devel] OpenEXR 1.5.0, OpenEXR-Images 1.5.0 released

[Florian Kainz]

I guess I my explanation should have been clearer.  Let me
try again:

For luminance, you want small quantization steps for small values
and large quantization steps for large values.  If v[i] is a
luminance value that can be represented exactly and v[i+1] is the
next larger value that can be represented exactly, then you want
the quantization step, v[i+1]-v[i], to be roughly proportional
to v[i].  Floating-point numbers behave like this by default.

For the two chroma channels, you want roughly equal quantization
steps throughout their valid range.  (Ideally, the quantization
steps for the chroma signals would be proportional to the size
of the McAdams ellipses, as mapped into the color space defined
by the equations for the chroma channels, but equal quantization
steps are good enough for our purposes.)
Inefficient quantization doesn't matter if the chroma channels
are encoded as 16-bit floating-point numbers; we have enough bits
to compensate for that.  However, quantization does matter for
B44 compression, where the chroma differences between adjacent
pixels are reduced to six bits.  B44 re-distributes the incoming
chroma values such that the integer difference t[j]-t[i] is roughly
proportional to the original floating-point difference s[j]-s[i].

I don't think I have the quantization backwards.  If you want to
see for yourself, go to function insertChannels() in ImfRgbaFile.cpp,
play with the settings of the the pLinear flags, and convert files
such as WideColorGamut.exr and GrayRampsHorizontal.exr from the
OpenEXR sample image collection to luminance/chroma format with B44
compression (at this point, only B44 pays attention to the pLinear
flags).

Regarding terminology - I think calling luminance perceptually
logarithmic is appropriate since perception of luminance obeys
obeys the Weber-Fechner law, at least approximately.

Florian


Chris Cox wrote:
> > The luminance channel is perceptually closer
> > to logarithmic than linear, and quantization steps should be proportional
> > to the magnitude of the values encoded in the file.  Chroma channels are
> > perceptually closer to linear than logarithmic; quantization steps should
> > be roughly the same throughout the range of encoded values.
>
> For a perceptually lossless encoding, you may have that backwards.
>
> Linear (gamma 1.0) data needs to be quantized with logarithmic or power law 
> steps.
> And log encoded or gamma encoded (aroung 2.0) data need to use fixed 
> quantization steps.
> (same as audio ;-)
>
> Fixed quantization of linear (gamma 1.0) image data leads to artifacts in the 
> shadows, and 75% of the values given to highlights (wasted).
> Fixed quantization of log or gamma 2.0 encoded image data leads to no visible 
> artifacts.
>
> If you're trying to say that the chroma channels are perceptually encoded (log 
> or gamma 2.0), then you have it right but are using confusing, non-standard 
> terminology.
>
> Also, the logarithmic nature of floating point shouldn't enter into the 
> discussion because they are still mathematically linear.
> Only the encoding of the original data should matter.
>
> Chris
>
>
>
> -----Original Message-----
> From: address@hidden on behalf of Florian Kainz
> Sent: Tue 12/19/2006 2:34 PM
> To: Florian Kainz
> Cc: Simon Green; address@hidden
> Subject: Re: [Openexr-devel] OpenEXR 1.5.0, OpenEXR-Images 1.5.0 released
>  
> P.S.: I missed a step in my description of B44.  In the latest version
> of OpenEXR, a new per-channel pLinear flag indicates if an image channel
> is perceptually linear or logarithmic.
>
> The B44 compressor uses this flag to reduce quantization artifacts in
> luminance/chroma images.  The luminance channel is perceptually closer
> to logarithmic than linear, and quantization steps should be proportional
> to the magnitude of the values encoded in the file.  Chroma channels are
> perceptually closer to linear than logarithmic; quantization steps should
> be roughly the same throughout the range of encoded values.
>
> In order to compensate for the logarithmic behavior of floating-point
> numbers, the B44 compressor warps the s[i] values in input blocks for
> perceptually linear channels before computing t[i]:
>
>      s[i] = min (exp (s[i] / 8), HALF_MAX)
>
> Note that this operation limits the range original pixel values that can
> be encoded to approximately [-88.7, 88.7], and that only 962 different
> warped s[i] values are produced.