"16-bit" mode.

On Sun, 21 Nov 2004 20:10:45 GMT, "Mike Russell"

Gama encoding compresses some data values, and there is
no reason to do this to raw data from a spacecraft.

And, there is no reason to do that to images from digital cameras
either, just like Adobe shows to us, the ARC (like most of the other
conversion sw too) perform all the processing in the linear domain.
Why, for the same reason why linear processing os done in scientific
imaging also, to avoid the Gamma Induced Errors.

Timo Autiokari http://www.aim-dtp.net

wrote in message
...
Kibo informs me that "Harvey" stated that:

"Toby Thain" wrote in message
.com...
wrote in message
Someone should tell adobe that we have fast machines now and can work
with accurate data.

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

They're correct - it is.

15bits gives you 5bits for R,G & B. There's no quality advantage between
15
vs. 16bits in terms of quality for RGB handling.

You're thinking of the HiColour video modes. The 15 bits we've been
talking about in PS is 15 bits *per colour*, per pixel, ie; a total of
45 bits per pixel.


Good to see somebody's awake.....................

wrote in message
...
Kibo informs me that "Harvey" stated that:

"Toby Thain" wrote in message
.com...
wrote in message
Someone should tell adobe that we have fast machines now and can work
with accurate data.

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

They're correct - it is.

15bits gives you 5bits for R,G & B. There's no quality advantage between
15
vs. 16bits in terms of quality for RGB handling.

You're thinking of the HiColour video modes. The 15 bits we've been
talking about in PS is 15 bits *per colour*, per pixel, ie; a total of
45 bits per pixel.


Good to see somebody's awake.....................

wrote in message
...
Kibo informs me that "Harvey" stated that:

"Toby Thain" wrote in message
.com...
wrote in message
Someone should tell adobe that we have fast machines now and can work
with accurate data.

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

They're correct - it is.

15bits gives you 5bits for R,G & B. There's no quality advantage between
15
vs. 16bits in terms of quality for RGB handling.

You're thinking of the HiColour video modes. The 15 bits we've been
talking about in PS is 15 bits *per colour*, per pixel, ie; a total of
45 bits per pixel.


Good to see somebody's awake.....................

Chris Cox wrote in message ...
In article , Dave Martindale
wrote:

(Toby Thain) writes:

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

When your source data was probably from a 12-bit ADC, or maybe 14-bit,
working with 15 significant bits may indeed be completely adequate. And
there *are* advantages to using a representation that has some headroom
for "whiter than white" without overflow, and where the representation
for "1.0" is a power of 2.

But the couple of most recent comments in this thread are about the fact
that Photoshop's greyscale doesn't even seem to have 15 significant
bits, unlike the RGB representation.

The color mode doesn't matter - it's still 16 bit data (0..32768).

It's deceptive to characterise that range of values as "16 bit" - it
has only 15 bits of dynamic range.


Chris

Chris Cox wrote in message ...
In article , Dave Martindale
wrote:

(Toby Thain) writes:

I've tried. Their engineer insists that it's 30x faster to work with
15 bit quantities than 16 bit ones.

When your source data was probably from a 12-bit ADC, or maybe 14-bit,
working with 15 significant bits may indeed be completely adequate. And
there *are* advantages to using a representation that has some headroom
for "whiter than white" without overflow, and where the representation
for "1.0" is a power of 2.

But the couple of most recent comments in this thread are about the fact
that Photoshop's greyscale doesn't even seem to have 15 significant
bits, unlike the RGB representation.

The color mode doesn't matter - it's still 16 bit data (0..32768).

It's deceptive to characterise that range of values as "16 bit" - it
has only 15 bits of dynamic range.


Chris

In article ,
Toby Thain wrote:
Chris Cox wrote in message
.. .

The color mode doesn't matter - it's still 16 bit data (0..32768).

It's deceptive to characterise that range of values as "16 bit" - it
has only 15 bits of dynamic range.

YM precision. Dynamic range is independent of the number of bits used to
represent an image.

In article ,
Toby Thain wrote:
Chris Cox wrote in message
.. .

The color mode doesn't matter - it's still 16 bit data (0..32768).

It's deceptive to characterise that range of values as "16 bit" - it
has only 15 bits of dynamic range.

YM precision. Dynamic range is independent of the number of bits used to
represent an image.

Timo Autiokari writes:

Gama encoding compresses some data values, and there is
no reason to do this to raw data from a spacecraft.

And, there is no reason to do that to images from digital cameras
either, just like Adobe shows to us, the ARC (like most of the other
conversion sw too) perform all the processing in the linear domain.
Why, for the same reason why linear processing os done in scientific
imaging also, to avoid the Gamma Induced Errors.

This is all fine if you can preserve the data at the width it was
originally captured: at least 12 bits per sample in digital cameras, up
to 16 bits for scientific cameras.

But if you convert it to 8 bits per sample to save space, you *need* to
apply non-linear tone compression to keep sufficient tonal resolution
in the shadows. The encoding called "gamma correction" does this very
well, even better than taking the logarithm of intensity. But Timo
tells people to use 8-bit linear data, which badly quantizes the shadow
detail, because he things linear is always better no matter how many
bits are used. He's wrong.

And it happens that 8 bit gamma-corrected samples are enough to capture
the whole intensity range that we can view *in a single image* with few
or no quantization artifacts. It is good enough for pictorial images
you are going to print, or display on screen. That's why it's so
popular - it works just fine for final output in pictorial photography.

On the other hand, it's useful to preserve 16 bits of data forever for
some applications with high dynamic range (e.g. X-ray images), and some
even require floating point to represent. It's often useful to do
intermediate computations with 16- or even 32-bit integer or floating
point.

Dave

Timo Autiokari writes:

Gama encoding compresses some data values, and there is
no reason to do this to raw data from a spacecraft.

And, there is no reason to do that to images from digital cameras
either, just like Adobe shows to us, the ARC (like most of the other
conversion sw too) perform all the processing in the linear domain.
Why, for the same reason why linear processing os done in scientific
imaging also, to avoid the Gamma Induced Errors.

This is all fine if you can preserve the data at the width it was
originally captured: at least 12 bits per sample in digital cameras, up
to 16 bits for scientific cameras.

But if you convert it to 8 bits per sample to save space, you *need* to
apply non-linear tone compression to keep sufficient tonal resolution
in the shadows. The encoding called "gamma correction" does this very
well, even better than taking the logarithm of intensity. But Timo
tells people to use 8-bit linear data, which badly quantizes the shadow
detail, because he things linear is always better no matter how many
bits are used. He's wrong.

And it happens that 8 bit gamma-corrected samples are enough to capture
the whole intensity range that we can view *in a single image* with few
or no quantization artifacts. It is good enough for pictorial images
you are going to print, or display on screen. That's why it's so
popular - it works just fine for final output in pictorial photography.

On the other hand, it's useful to preserve 16 bits of data forever for
some applications with high dynamic range (e.g. X-ray images), and some
even require floating point to represent. It's often useful to do
intermediate computations with 16- or even 32-bit integer or floating
point.

Dave