16 bit linear scan: what is it good for?

  • Thread starter Thread starter Alex
  • Start date Start date
A

Alex

Hello all,

The Dimage scan dual IV has, besides 8 and 16 bit scan modus, also a
16 bit linear modus. The manual is not very clear about its
usefulness, but I have the feelling that it must be good for
something.
Who can enlighten me on the subject, or direct me to an enlightening
link?

Thanks in advance for the response.
 
Hello all,

The Dimage scan dual IV has, besides 8 and 16 bit scan modus, also a
16 bit linear modus. The manual is not very clear about its
usefulness, but I have the feelling that it must be good for
something.
Who can enlighten me on the subject, or direct me to an enlightening
link?

16-bit/channel linear scan data is the best basis for further
postprocessing. The most significant step, either by the scanner software or
by a photoeditor application, is gamma adjustment to offset the
display/monitor gamma. It is better to apply as many corrections as needed
in a single step rather than in subsequent steps, because each individual
calculation step introduces rounding errors. These errors can cumulate into
visible artifacts.

There will be little visible deterioration from gamma correction by the scan
software, followed by a small number of separate postprocessing steps, but
with each step the data quality will be reduced, so keeping the number of
steps limited to a few is best.

Bart
 
Bart van der Wolf said:
16-bit/channel linear scan data is the best basis for further
postprocessing. The most significant step, either by the scanner
software or
by a photoeditor application, is gamma adjustment to offset the
display/monitor gamma. It is better to apply as many corrections as
needed
in a single step rather than in subsequent steps, because each
individual
calculation step introduces rounding errors. These errors can
cumulate into
visible artifacts.

There will be little visible deterioration from gamma correction by
the scan
software, followed by a small number of separate postprocessing
steps, but
with each step the data quality will be reduced, so keeping the
number of
steps limited to a few is best.

Bart

Thank you for the explanation. There is still the matter of "16 bit"
versus "16 bit linear" : has one or the other been changed from the
original data as they have been acquired? A gamma correction perhaps?
 
Thank you for the explanation. There is still the matter of "16 bit"
versus "16 bit linear" : has one or the other been changed from the
original data as they have been acquired? A gamma correction perhaps?

Yes, gamma correction (making it non-linear) and some basic color balancing.

Bart
 
Bart van der Wolf said:
16-bit/channel linear scan data is the best basis for further
postprocessing. The most significant step, either by the scanner software or
by a photoeditor application, is gamma adjustment to offset the
display/monitor gamma. It is better to apply as many corrections as needed
in a single step rather than in subsequent steps, because each individual
calculation step introduces rounding errors. These errors can cumulate into
visible artifacts.

There will be little visible deterioration from gamma correction by the scan
software, followed by a small number of separate postprocessing steps, but
with each step the data quality will be reduced, so keeping the number of
steps limited to a few is best.

Bart

I think it interchangable with a Vuescan "raw file", for
scan-from-disk workflow, within that program. Though, I would prefer
to create such "raw file" from within Vuescan. Minolta explained
nothing regarding this format in my Scan Dual II manual.
 
Bart van der said:
16-bit/channel linear scan data is the best basis for further
postprocessing. The most significant step, either by the scanner software or
by a photoeditor application, is gamma adjustment to offset the
display/monitor gamma.

No.

Gamma encoding of the image has nothing to do with the display transfer
function.

Gamma encoding of the image is done to maximize the usage of the bits
for human vision and give the image a nearly perceptual encoding (which
are different ways of saying the same thing).

Chris
 
Chris Cox said:
No.

Gamma encoding of the image has nothing to do with the display transfer
function.

Nothing, seems a bit too strong. Besides, why is there a different gamma
needed for Mac display versus Windows? The LUTs for video display have a
different gamma encoding that needs to be compensated for.
Gamma encoding of the image is done to maximize the usage of the bits
for human vision and give the image a nearly perceptual encoding (which
are different ways of saying the same thing).

The question is; is the more efficient usage of bits the result, or the goal
of the exercise?
The reciprocal gamma adjustment applied to the scan data, is reversed by the
native gamma of the display. Where has the perceptual encoding gone? It only
adds some accuracy, but has no effect on human perception (which also looks
at a linear gamma real world photon flux). Based on that photon flux, the
human visual system does respond to luminance differences in a somewhat
logarithmic sense.

What's more, also Photoshop does some of its (blending) processing in linear
gamma space, requiring to temporarily reverse the gamma encoding (=loss of
accuracy) of the file.
Major rendering packages often use linear gamma, because it is a benefit for
calculating, but the storage can be done in a number of different encodings
(=coding efficiency/accuracy).

Finally, after all those calculations, the data must be displayed/printed on
a device that has a native gamma, and a compensating correction is needed.

Bart
 
Hello all,

The Dimage scan dual IV has, besides 8 and 16 bit scan modus, also a
16 bit linear modus. The manual is not very clear about its
usefulness, but I have the feelling that it must be good for
something.
Who can enlighten me on the subject, or direct me to an enlightening
link?

Thanks in advance for the response.

I have tried using the 16 Bit Linear output on B&W negative scans on
my Dimage dual IV, but the image is clipped in the lowest density
areas of the negative. The main exposure adjustment on the exposure
tab has some effect on the linear image, but it does not eliminate the
extensive clipping. Because of this result specifically with the
Dimage dual IV I would not suggest using it the same way as a Vuescan
raw file unless you check it carefully for full dyanmic range.

The Vuescan raw output with the Diamge dual IV is not clipped like the
Konica Minolta software linear output, so it can produce a usable
image.
 
Al said:
On Tue, 04 May 2004 04:10:34 -0500, Alex <> wrote: SNIP
I have tried using the 16 Bit Linear output on B&W negative scans on
my Dimage dual IV, but the image is clipped in the lowest density
areas of the negative.

Have you tried scanning it as a positive, then invert and gamma adjust in
the photoeditor? It may sound odd, but that should work better than scanning
it as a negative. The Minolta software has a problem scanning negatives
without clipping.

Bart
 
Bart van der Wolf said:
Nothing, seems a bit too strong. Besides, why is there a different gamma
needed for Mac display versus Windows? The LUTs for video display have a
different gamma encoding that needs to be compensated for.

No, it's not too strong. The image encoding has nothing to do with the
display transfer curve/function.

And yes, Macintosh and Windows have different default gamma values -
but that's just for display. The Macintosh was compensating in a way
that made images appear correct and print with minimum change on
certain printing devices. Thus the default Macintosh gamma factor is
1.8, but you can change it. And you can have each display on the
system using a different tone response curve. It's up to the OS or the
application to correct the image for each display.

The question is; is the more efficient usage of bits the result, or the goal
of the exercise?

The goal - it seems to have been created for television (the first real
image encoding system other than paint) to maximize the use of the
available bandwidth.

They also lucked out that the encoding came close to compensating for
the physics of CRTs (reducing the circuitry necessary for early TV).

The reciprocal gamma adjustment applied to the scan data, is reversed by the
native gamma of the display. Where has the perceptual encoding gone?

After going through the whole system of photons back to photons -- it
almost disappears, as it should (it can't completely because the
original scene has higher dynamic range than the viewing system, and
there has to be some tonal compression).

But if you stored the image in gamma 1.0 (linear light), you'd need 2
to 4 more bits per channel to get the same visual quality.


It only adds some accuracy, but has no effect on human perception
(which also looks at a linear gamma real world photon flux).

Flux and perception are very different things.
(which many people have confused)

Based on that photon flux, the
human visual system does respond to luminance differences in a somewhat
logarithmic sense.

Yes - and over a small range, a power function (gamma) is similar to
the logarithmic response.

What's more, also Photoshop does some of its (blending) processing in linear
gamma space, requiring to temporarily reverse the gamma encoding (=loss of
accuracy) of the file.

Yes. And there is no loss of accuracy if you use a higher precision
intermediate value.

Major rendering packages often use linear gamma, because it is a benefit for
calculating, but the storage can be done in a number of different encodings
(=coding efficiency/accuracy).
Yes.


Finally, after all those calculations, the data must be displayed/printed on
a device that has a native gamma, and a compensating correction is needed.

Yes, but it doesn't have to be stored in the file using the same
compensating factor as the display.
Do you really think your LCD display has a gamma similar to a CRT?
Even using linear displays, you're better off using a gamma encoding in
the file format to get the best visual quality for the available bits.

See http://chriscox.org/gamma/

Chris
 
Back
Top