Digital BW, The Print

To help me with the adaption of the Wasatch SoftRip for quad
printing a friend wrote a small PC application to convert 8 bit
and 16 bit greyscale files to plain 8 bit or 16 bit cmyk files.
No separation is done just 4 copies of the greyscale gathered and
given the C,M,Y,K, mark. Similar to what can be done with a
PhotoShop action. He also added a choice of compression, LZW,
ZIP, RLE or none. The ZIP compression is not accepted by the RIP
but PhotoShop does, with that kind of CMYK files the size is then
a bit smaller than the original greyscale file.
I wonder whether it has any sense to make the application
available on my site, with the LZW compression added it isn't
wise to put in the file section of this list.

Following a small thread here (OPM in theory) on the conversion
of 8 bit greyscale to 16 bit I asked him whether it could be
added to the same application with the bit shifts as discussed
here. He made some comments I like to add (my translation):

Quote:
From the discussion I gather there are three variants:

i8  :   8 bits grey values (0-255)
i16: 16 bits grey values (0-65535)

A) i16 = 256*i8
B) i16 = 257*i8
C) i16 = 256*i8 + random(0,256)

I consider B to be the only correct one. With that the complete 8
bit intensity range is scaled to the complete 16 bits range.
Software writers tend to do A that gives a small offset and a bit
lower contrast. Some people in the discussion had high hopes for
C. I don't get how you can get a better result by introducing a
random falt of half the step value on purpose. Best guess is that
it tries to generate a random dithering. I seems to me that the
dithering process should be done on results obtained with exact
computations.

If there's a desire to experiment I can add a 8-16 bit conversion
option with a choice between B and C. Any thoughts on the random
function in C are welcome. It can be a uniform distribution where
all the numbers get an equal chance. A normal distribution may be
better, the numbers further from the middle get a lower chance.

Gert-Jan

End of quote, translation by Ernst


Ernst

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Ernst 
Dinkla" <E.Dinkla@c...> wrote:
> To help me with the adaption of the Wasatch SoftRip for quad
> printing a friend wrote a small PC application to convert 8 bit
> and 16 bit greyscale files to plain 8 bit or 16 bit cmyk files.
> No separation is done just 4 copies of the greyscale gathered 
and
> given the C,M,Y,K, mark. Similar to what can be done with a
> PhotoShop action. He also added a choice of compression, 
LZW,
> ZIP, RLE or none. The ZIP compression is not accepted by the 
RIP
> but PhotoShop does, with that kind of CMYK files the size is 
then
> a bit smaller than the original greyscale file.
> I wonder whether it has any sense to make the application
> available on my site, with the LZW compression added it isn't
> wise to put in the file section of this list.
> 
> Following a small thread here (OPM in theory) on the 
conversion
> of 8 bit greyscale to 16 bit I asked him whether it could be
> added to the same application with the bit shifts as discussed
> here. He made some comments I like to add (my translation):
> 
> Quote:
> From the discussion I gather there are three variants:
> 
> i8  :   8 bits grey values (0-255)
> i16: 16 bits grey values (0-65535)
> 
> A) i16 = 256*i8
> B) i16 = 257*i8
> C) i16 = 256*i8 + random(0,256)
> 

Ernst,

I agree that B is the only correct one and btw, what PS does.

C is probably fairly harmless for most of the range,  but I think
at the end points you'll end up with some undesirable side
effects.   Consider white=(8bit)0, if that gets converted to
(16)bit0+random_number  its no longer white.  Its effect will
be to increase dMin by half a unit and decrease dMax by
half a unit.

Roy

> I consider B to be the only correct one. With that the complete 8
> bit intensity range is scaled to the complete 16 bits range.
> Software writers tend to do A that gives a small offset and a bit
> lower contrast. Some people in the discussion had high hopes 
for
> C. I don't get how you can get a better result by introducing a
> random falt of half the step value on purpose. Best guess is 
that
> it tries to generate a random dithering. I seems to me that the
> dithering process should be done on results obtained with 
exact
> computations.
> 
> If there's a desire to experiment I can add a 8-16 bit conversion
> option with a choice between B and C. Any thoughts on the 
random
> function in C are welcome. It can be a uniform distribution 
where
> all the numbers get an equal chance. A normal distribution 
may be

> better, the numbers further from the middle get a lower chance.
> 
> Gert-Jan
> 
> End of quote, translation by Ernst
> 
> 
> Ernst

Ernst,

thanks for that very useful discussion of the 8 vs 16 bit issue. I wonder if it 
explains some of the issues OPM had with accepting 8bit files.
In any case, I don't see why we couldn't upload the app here - unless there is 
some licence infringment with the LZW.  
Otherwise, I suppose all this can be accomplished in Photoshop as well, but 
would be interesting to have all three choices available for purposes of 
demonstration or troubleshooting.

Antonis

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Antonis Ricos"
<antonisphoto@y...> wrote:
...
> Otherwise, I suppose all this can be accomplished in Photoshop as well

Yes, it's easily accomplished in Photoshop, with the below caveats.
Ernst may have some reason for doing it outside of Photoshop, not sure
about that.
Photoshop actually doesn't have full 16 bit capability. Not sure why,
but all of the theoretically possible hi bit levels are not available
in Photoshop. If you can create a true 16 bit file, as soon as you
open it and save it in PS some levels will be thrown out, even with no
editing.
So if you are really picky about this, I supposed an alternative app
for conversion may be usefull, particularly if you can spool it to the
RIP outside of PS, as Ernst is doing.
On the other hand, a true one channel to four channel conversion of a
high bit gray original may already be less than ideal, since it was
probably edited and saved in PS to begin with. Therefore the three new
identical channels will also be slightly less than full. If some other
method of conversion stretches the levels out a hair via noise or
whatever, that's a different story.
This is all just yakking, I doubt the difference between a hi bit PS
file and a true hi bit file is worth fretting over, but it erks me a bit.
For info on PS's idea of hi bit, see Bruce Lindbloom's site.
Tyler

--- In DigitalBlackandWhiteThePrint@yahoogroups.com, "Tyler 
Boley" <tyler@t...> wrote:
> --- In DigitalBlackandWhiteThePrint@yahoogroups.com, 
"Antonis Ricos"
> <antonisphoto@y...> wrote:
> ...
> > Otherwise, I suppose all this can be accomplished in 
Photoshop as well
> 
> Yes, it's easily accomplished in Photoshop, with the below 
caveats.
> Ernst may have some reason for doing it outside of 
Photoshop, not sure
> about that.
> Photoshop actually doesn't have full 16 bit capability. Not sure 
why,
> but all of the theoretically possible hi bit levels are not available
> in Photoshop. If you can create a true 16 bit file, as soon as you
> open it and save it in PS some levels will be thrown out, even 
with no
> editing.

Very true.  PS really only uses 15 bits internally.  The bottom
bit is dropped off.  Then when you Save it fills in a "made up"
bottom bit .  It may be mathematically irksome but makes no
practical difference.

Roy

> So if you are really picky about this, I supposed an alternative 
app
> for conversion may be usefull, particularly if you can spool it to 
the
> RIP outside of PS, as Ernst is doing.
> On the other hand, a true one channel to four channel 
conversion of a
> high bit gray original may already be less than ideal, since it 
was
> probably edited and saved in PS to begin with. Therefore the 
three new
> identical channels will also be slightly less than full. If some 
other
> method of conversion stretches the levels out a hair via noise 
or
> whatever, that's a different story.
> This is all just yakking, I doubt the difference between a hi bit 
PS

> file and a true hi bit file is worth fretting over, but it erks me a bit.
> For info on PS's idea of hi bit, see Bruce Lindbloom's site.
> Tyler