"16-bit" mode.

Kibo informs me that (Dave Martindale) stated that:

Matt Austern writes:

Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right.

He is.

I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.

One guess: checking for overflow in filtering.

Close. The short answer is that it provides room for intermediate
results that are guaranteed not to overflow a machine register. This is
a huge performance win for operations that are going to be repeated for
every pixel in a big dataset, because it means that you don't need to
include a conditional branch to check for overflow at every step in the
computation.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Kibo informs me that (Dave Martindale) stated that:

Matt Austern writes:

Nope. If Chris says 16-bit image processing in Photoshop would be much
slower than 15, I have no doubt that he's right.

He is.

I just don't know
why. I can easily believe there's some subtle algorithmic issue that
I haven't thought of. For that matter, I can easily believe there's
some glaringly obvious algorithmic issue I haven't thought of. I'm
just curious what it might be.

One guess: checking for overflow in filtering.

Close. The short answer is that it provides room for intermediate
results that are guaranteed not to overflow a machine register. This is
a huge performance win for operations that are going to be repeated for
every pixel in a big dataset, because it means that you don't need to
include a conditional branch to check for overflow at every step in the
computation.

--
W
. | ,. w , "Some people are alive only because
\|/ \|/ it is illegal to kill them." Perna condita delenda est
---^----^---------------------------------------------------------------

Sorry; I forgot one step.

In message , I,
wrote:

In message ,
wrote:

And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.

You don't need to enter through .raw to see the problem; just open a new
2x1 pixel document in greyscale mode.

Make one pixel 0 and the other 1 (out of 255).

Convert to 16-bit. Bicubic
resize the 2x1 pixel image to 500x1. Set "Info" to give 16-bit values.
Make sure the color sampling tool is set to single pixel. put the
pointer over the string of pixels. See if there are any gaps in the
numbers.

--


John P Sheehy

Sorry; I forgot one step.

In message , I,
wrote:

In message ,
wrote:

And speaking of supplying original data, where the hell does Adobe keep
the PS raw file format doc's that used to be on the website? - I wanted
to try John's experiment for myself, but all I could find was the PS
SDK, for which Adobe wants money.

You don't need to enter through .raw to see the problem; just open a new
2x1 pixel document in greyscale mode.

Make one pixel 0 and the other 1 (out of 255).

Convert to 16-bit. Bicubic
resize the 2x1 pixel image to 500x1. Set "Info" to give 16-bit values.
Make sure the color sampling tool is set to single pixel. put the
pointer over the string of pixels. See if there are any gaps in the
numbers.

--


John P Sheehy

In message ,
wrote:

Close. The short answer is that it provides room for intermediate
results that are guaranteed not to overflow a machine register. This is
a huge performance win for operations that are going to be repeated for
every pixel in a big dataset, because it means that you don't need to
include a conditional branch to check for overflow at every step in the
computation.

It also allows you to perform some operations on multiple data values at
the same time, as their carry-overs won't spill into another data value.
--


John P Sheehy

In message ,
wrote:

Close. The short answer is that it provides room for intermediate
results that are guaranteed not to overflow a machine register. This is
a huge performance win for operations that are going to be repeated for
every pixel in a big dataset, because it means that you don't need to
include a conditional branch to check for overflow at every step in the
computation.

It also allows you to perform some operations on multiple data values at
the same time, as their carry-overs won't spill into another data value.
--


John P Sheehy

In message ,
Chris Cox wrote:

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.

I just came up with an idea to check if it was the internal
representation or the "info" tool itself, and sure enough it was the
info tool that was at fault.

What I did was open the "levels" dialog, and set the input max to 2.
Then, I moved the info tool over the pixels, and sure enough, there was
not a direct correspondence between the "old" and "new" values. the
first 0 became a 0; the second 0 became a 52; all numbers that are
multiples of 52 were present in the new values (no gaps).

The info tool is toast in 16-bit greyscale mode.
--


John P Sheehy

In message ,
Chris Cox wrote:

I do know that for anyone else doing a similar experiment (inside and
outside Adobe), they get the full 32769 values.

I just came up with an idea to check if it was the internal
representation or the "info" tool itself, and sure enough it was the
info tool that was at fault.

What I did was open the "levels" dialog, and set the input max to 2.
Then, I moved the info tool over the pixels, and sure enough, there was
not a direct correspondence between the "old" and "new" values. the
first 0 became a 0; the second 0 became a 52; all numbers that are
multiples of 52 were present in the new values (no gaps).

The info tool is toast in 16-bit greyscale mode.
--


John P Sheehy

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

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