16/48 bit plugin notes
Chris Russ
I wrote my first 16/48 plug-in today (as opposed to well over a hundred
of the ordinary variety). Basically it amounted to figuring out what
the differences in the data formats were so everything would be cool.
Macsbug is my friend. ;-)
Not everything was the way I expected it, however. For instance:
White is 32768, 32768, 32768. (hex 0x8000, 0x8000, 0x8000).
NOT 65535, 65535, 65535 as expected or 32767, 32767, 32767
Black is 0, 0, 0 as expected (whew!)
The selection plane is still unsigned characters, even though the
opacity plane and color planes now take 16 bits. This is good, but I
half expected (feared?) it to also be 16-bit.
If you look at which tools work and don't, it becomes clear that they
didn't want to write any code for brushes and the like that would
require dealing with 16-bit opacity. (Not a surprise, or a problem.)
Aren't deadlines a pain? There comes a point where you have to take the
program away from the engineer and ship it.
The use of only part of the range (0..32768), at least as provided to
the filters, suggests that the images are really 15/45 not 16/48. I
challenge anyone to notice the difference, but I'm a bit surprised and
disappointed that the full range isn't used and there is little or no
documentation on 16/48 plug-in interfaces.
However, there has been some discussion about conversion from 16->8
bits. I did a little big of quick checking to see how the
rounding/truncation works to see if there was a real problem or not.
Going from 8 -> 16 (or 15)
Black 0 -> Black 0
Black 1 -> Black 0x0081 (or 129)
...
White 254 ->White 0x7F7F (or 32639)
White 255 -> White 0x8000 (or 32768) technically 16 bits, although just
barely
When that 16 bit image is up and the eyedropper tool is used, it reports
color components 0..255, so let's try to see where the rounding occurs
from 254 to 255
By making an image with a ramp that is nearly pure white:
... 7FB0 7FAF 7FAE 7FAD 7FAC 7FAB 7FAA 7FA9
7FA8 7FA7 7FA6 7FA5 7FA4 7FA3 7FA2 7FA1
7F9F 7F9E 7F9D 7F9C 7F9B 7F9A 7F99 7F98
...
The transition from 255 to 254 in the info window is right at 7FA0
(32672). This is halfway between 0x8000 and 0x7F7F which is what we
would expect for a rounding off point. Thus, it appears that at least
for the eyedropper and conversion on the screen, bits are dropped
carefully and with rounding.
However, it isn't that simple when you drop from 16 bits per channel to
8 bits per channel. The rounding cutoff point is dithered around a bit
to prevent banding when dropping the bits. This is a very smart way to
solve the problem. An image that was 8/24 and is converted to 16/48
will convert back to exactly the same colors. However an image that is
16/48 will drop down pretty well to 8/24, but the transition point
between 255 and 244 (from 32768..32639) will move around a little to
prevent a really harsh line for the transition. This method is not the
same as spatial averaging or dithering. Technically if you're looking
for a reference, look in Foley and Van Dam, _Computer Graphics_ for
"Ordered Dithering."
I haven't run any tests to see if the transition effect is random or a
structured pattern (and have no inclination at this point), but it
appears that Adobe did everything right. There are some smart cookies
over there.
The only thing that concerns me is the 15 vs. 16 bit issue, but it is
really hard to get a detector that has more than 12..14 real bits. Even
a cooled-CCD camera can't do that well.
So, now that it is possible to make plug-ins that are 16/48, which ones
should we make?
-Chris Russ
Timo Autiokari
>An image that was 8/24 and is converted to 16/48 will convert back
>to exactly the same colors.
No, 8/24 image it does _not_ convert exactly, there will be a lot of noise
pixels. To verify do the following:
1. Open a 8/24 image (with no layers).
2. Duplicate it.
3. Convert the duplicate into 16-bit mode.
4. Convert the duplicate into 8-bit mode.
5. Do Image/Apply_Image on the duplicate
with the following setting:
Source: the original image
Layer: Background
Channel: RGB
Blending: Difference
Opacity 100%
6. Press OK.
7. Do Image/Adjust/Levels and enter the value 2
into the right input box, and press OK.
8. View the image at 200% zoom.
So the Photoshop Induced Noise problem is one RGB level random noise in the
8/24 bit space (and _not_ one RGB level in the 16/48 bit space). This is a
serious flaw in Photoshop and hits everyone who use higher bit-depth acquire
devices.
>The only thing that concerns me is the 15 vs. 16 bit issue
Yes, Photoshop has only 15-bit space, not 16-bit mode !
I created a gradation from level 0 to level 255 with one level steps in double
byte hex (16-bit space) using VisualBasic for Application, saved this as
gradation.raw. Opened it into Photoshop, saved it as gradation.psd, closed
this and re-opened it, then saved it as gradation_ps.raw. Now the
gradation.raw and gradation_ps.raw should be the exactly the same, but there
are only 128 different values in the gradation_ps.raw, stepping is by two
levels. So one bit is missing, it is only 15-bit space.
This also means that when the acquire device is 12/36 bit and it's Twain
acquire module scales it into 16/48 bit range then:
Photoshop only holds 11/33 bits, not the 12/36 bit !
And then when this 11/33 bit image is converted into 8/24 bit mode, Photoshop
will in addition apply the 1 RGB level noise in that 8/24 bit space.
This implies that considerable better scans can be acquired by doing the
higher-bit scans using Photo-Paint, I will experiment this as soon as possible
(the example on my www page was scanned using Photoshop and this scan was the
starting point for the conversion-noise comparison between Photoshop and
Photo-Paint).
I changed the 16-bit "gradation.raw" file into 16-bit "gradation.tif" (because
Photo-Paint does not read such raw files), opened this tif into Photo-Paint
and saved it as "gradation_pp.tif" and this file has all the 256 levels
intact. So Photo-Paint has 16-bit mode.
Timo Autiokari
Chris Russ
I wrote:
> >The only thing that concerns me is the 15 vs. 16 bit issue
>
Timo then wrote:
> Yes, Photoshop has only 15-bit space, not 16-bit mode !
>
> I created a gradation from level 0 to level 255 with one level steps in double
> byte hex (16-bit space) using VisualBasic for Application, saved this as
> gradation.raw. Opened it into Photoshop, saved it as gradation.psd, closed
> this and re-opened it, then saved it as gradation_ps.raw. Now the
> gradation.raw and gradation_ps.raw should be the exactly the same, but there
> are only 128 different values in the gradation_ps.raw, stepping is by two
> levels. So one bit is missing, it is only 15-bit space.
>
> This also means that when the acquire device is 12/36 bit and it's Twain
> acquire module scales it into 16/48 bit range then:
>
> Photoshop only holds 11/33 bits, not the 12/36 bit !
---
Duh, with your 12/36-bit scanner it is the bottom bit of the 16/48 that is lost.
It is inconsequential since only the top 12 bits per channel were real. Get a
life.
(There is no way that Photoshop, which is handed a 16/48 image from the twain
driver [carefully bit-shifted << 4], could know which of the bits is the bottom
bit from your device and deliberately trash it.)
If you feel so strongly about not going to 8/24, then DON'T. Write all of the
tools you need to stay in 16/48 (or 15/45, whatever).
Adobe has done a very good job. They have consistently done as much of "the
right thing" as they could. They weren't trying to make a product that would
allow you to do everything in 16/48. There isn't that much call for it anyway
and here comes a point where you have to ship it.
All I was trying to find out was what kinds of plug-ins in 16/48 would make sense
to write.
-Chris Russ
tim...@clinet.fi
jc...@aol.com wrote:
> Duh, with your 12/36-bit scanner it is the bottom bit of the
> 16/48 that is lost.It is inconsequential since only the top
> 12 bits per channel were real. Get a life.
In this _special_ case where you drop the 12/36 image into 8/24
right-after-the-acquire _then_ nothing is lost. No one does imaging like this.
We acquire in higher bit-depth in order to edit the image there.
Editing will remap the levels, when the 12-bit real-data that is scaled to the
15-bit space of Photoshop is edited, it will not anymore be evenly spaced in
that 15-bit space. If you do Levels, Curves and Hue/Sat then all/most of the
levels in the 15-bit space will be occupied by: edited-real-data. And that is
only half of that of the 16-bit space, so you lose every other code.
> Adobe has done a very good job. They have consistently done as much of "the
> right thing" as they could. They weren't trying to make a product that would
> allow you to do everything in 16/48.
-Nothing- in Photoshop can be done in 16-bit, it is only 15-bit. They
advertice it as being partially 16-bit but it is simply not true.
> All I was trying to find out was what kinds of plug-ins in 16/48 would
> make sense to write.
There are already 15-bit filters for the Mac version:
http://www.scanprep.com/sets/dbf/content.html
http://www.scanprep.com/sets/dbf/prod/ps-dbf.html
these 6 filters cost $95.
I will pay 10 times of that for 7 filters for Windows version, those above +
a clean conversion from the 15-bit to 8-bit space, provided that they work
similarly like they now work in the 8-bit (especially the USM; radius 0.5
keeps the effect withing the two edge pixels) but so that one decimal can be
entered for the radius in the other filters too and that Despeckle has Amount
(since there is no Fade available in the 15-bit space).
Timo Autiokari
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Dave Martindale
>We acquire in higher bit-depth in order to edit the image there.
>Editing will remap the levels, when the 12-bit real-data that is scaled to the
>15-bit space of Photoshop is edited, it will not anymore be evenly spaced in
>that 15-bit space. If you do Levels, Curves and Hue/Sat then all/most of the
>levels in the 15-bit space will be occupied by: edited-real-data. And that is
>only half of that of the 16-bit space, so you lose every other code.
The original data converted to 15 bit has code values that are spaced apart
by 8. Doing image operations fills in those "in between" values, so you
eventually do have 15-bit-wide modified data. So these results have 15-bit
precision, which isn't quite as good as 16-bit, but still far better than
the original 12-bit. You haven't lost anything from the original, and
in fact you have 3 *extra* bits of precision in the editing results.
You just don't have the 4 extra bits you'd expect from the "16-bit" name.
But can you see the difference between 15 and 16 bits for intermediate
results, when the original data is only 12, and when the output data
is just 8 bits wide? Very seldom. Even if the output was still 12
bits, you'd seldom see the difference between 15 and 16 bit intermediate
calculations.
>> Adobe has done a very good job. They have consistently done as much of "the
>> right thing" as they could. They weren't trying to make a product that would
>> allow you to do everything in 16/48.
>-Nothing- in Photoshop can be done in 16-bit, it is only 15-bit. They
>advertice it as being partially 16-bit but it is simply not true.
Photoshop 4 was true 16-bit. I wonder why they changed for Photoshop 5?
I can think of two possibilities:
- making the largest value 32767 allows using hardware multiply on
machines that have signed 16x16->32 multiply, but lack an unsigned
version of the same operation
- If the maximum value is 32768, not 32767, that allows rescaling the
32-bit result of a multiply back to 16 bits using a right-shift only.
If the maximum value is 65535, doing a right-shift introduces an
error in the result and you either have to live with it or do an
(expensive) division.
Either of these is a good reason to choose 15-bit precision in a 16-bit
word if you eventually plan on implementing filters that work in 16 bits.
In PS4, about the only things you could do with 16-bit data could be done
with lookup tables, so there was no penalty for full 16-bit representation.
A long time ago, there was a device called the Pixar Image Computer.
It did something similar for its number representation. It had a 12-bit
sample size in memory, but used 2048 to represent 1.0 (white). Codes
from 2048 to 3071 were "whiter than white", while codes from 3072 to 4095
were actually negative numbers. This allowed a power of 2 for "1",
so you get accurate multiplication with post-shifting (the hardware used
couldn't divide at all). And you could do image processing using filters
with negative lobes, and do chains of operations without worrying about
clipping values below 0 or above 1.
I mention this as an example of why it's sometimes reasonable to choose
something other than 2^N-1 as the code for "white" in an N-bit image
representation. Sometimes losing one bit of precision in intensity
lets you do *much* faster or more accurate arithmetic.
(My own image handling code mostly uses floating point, allowing the
hardware to handle all the details of scaling and normalization after
multiplies. But it means the intermediate results take twice the space
of 16-bit integer storage, and it costs 4 or more operations per pixel
just to read and write the image: int->float, divide, multiply,
float->int. That would be impractical for Photoshop).
It would be interesting if someone from Adobe would describe why they
chose the representation they did.
In any case, Photoshop 5 uses "15-bit" representation in 16-bit storage,
which is just fine for 12- and even 14-bit source images - which covers
most of digital photography. The astronomers with true 16-bit data
probably should use some other software for analyzing their images.
Dave
Chris Cox
> >-Nothing- in Photoshop can be done in 16-bit, it is only 15-bit. They
> >advertice it as being partially 16-bit but it is simply not true.
>
> Photoshop 4 was true 16-bit. I wonder why they changed for Photoshop 5?
> I can think of two possibilities:
>
> - making the largest value 32767 allows using hardware multiply on
> machines that have signed 16x16->32 multiply, but lack an unsigned
> version of the same operation
Nope, most machines have the unsigned mutiply, but having some extra
headroom to prevent overflow is a GOOD thin.
>
> - If the maximum value is 32768, not 32767, that allows rescaling the
> 32-bit result of a multiply back to 16 bits using a right-shift only.
> If the maximum value is 65535, doing a right-shift introduces an
> error in the result and you either have to live with it or do an
> (expensive) division.
Got that right. Even doing it with a 32 bit exact reciprocal is expensive.
> Either of these is a good reason to choose 15-bit precision in a 16-bit
> word if you eventually plan on implementing filters that work in 16 bits.
> In PS4, about the only things you could do with 16-bit data could be done
> with lookup tables, so there was no penalty for full 16-bit representation.
Think about blending -- where some blend modes need a 'neutral' or 'middle'
value. Hard to do that in a 0...255 or 0...65535 space.
Some very respected graphics gurus have recommended even fewer bits be used
to allow for more headroom. (especially when they're discussing video)
Chris
Chris Cox
> In article <37123D34...@aol.com>,
> jc...@aol.com wrote:
>
> > Duh, with your 12/36-bit scanner it is the bottom bit of the
> > 16/48 that is lost.It is inconsequential since only the top
> > 12 bits per channel were real. Get a life.
>
> In this _special_ case where you drop the 12/36 image into 8/24
> right-after-the-acquire _then_ nothing is lost. No one does imaging like this.
>
> We acquire in higher bit-depth in order to edit the image there.
>
> Editing will remap the levels, when the 12-bit real-data that is scaled to the
> 15-bit space of Photoshop is edited, it will not anymore be evenly spaced in
> that 15-bit space. If you do Levels, Curves and Hue/Sat then all/most of the
> levels in the 15-bit space will be occupied by: edited-real-data. And that is
> only half of that of the 16-bit space, so you lose every other code.
Timo, you're making even less sense than normal here.
If you've got 12 bits per channel (4096 levels) then moving that into a 15
or 16 bit space will still have 4096 levels.
Chris