From: "Mike McNamee Compuserve", INTERNET:mikemcnamee@compuserve.com
Date: Mon, Apr 23, 2001, 5:00 AM
RE: [colortheory] Lab Conversion in 6.0

Am I missing something?
I have always thought that moving from either CMYK or RGB to Lab and back
was a damage free process, that is, you would end up with the same color
co-ordinates when you arrived back from Lab mode. I have noticed with
PhotoShop 6 that repeated visits to Lab from CMYK gradually degrades the
colour so that after 25 transformations you are almost down to a grey image.
This does not happen in version 5.5. This has some implications for those of
us who convert to Lab mode to do some sharpening if carefully crafted
colours are messed about with!
Mike McNamee
Editor
Digital Photographer & Creative Imaging------------------------------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 9:49 AM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 4:01 AM, Mike McNamee Compuserve at mikemcnamee@compuserve.com
wrote:
> I have always thought that moving from either CMYK or RGB to Lab and back
> was a damage free process, that is, you would end up with the same color
> co-ordinates when you arrived back from Lab mode.
Nope. At least not on 24 bit color. There are rounding issues (quantization
errors) that do produce some degree of damage. ANY colorspace conversion can
cause these quantization errors (RGB to RGB as an example). When you do a
conversion from RGB to RGB and the gamma of the two spaces match, the loss
if far less. This by the way is NOTHING new with Photoshop 6.
Andrew Rodney
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Mon, Apr 23, 2001, 11:18 AM
RE: [colortheory] Lab Conversion in 6.0

Mike McNamee writes,
>>I have always thought that moving from either CMYK or RGB to Lab and back
was a damage free process, that is, you would end up with the same color
co-ordinates when you arrived back from Lab mode.>>
RGB>LAB>RGB is damage free, but CMYK>LAB>CMYK is not. The damage isn't all
that great, so in many images it pays to come out of CMYK so as to take
advantage of LAB's strengths; sharpening, however, is not one of these
cases.
>>I have noticed with PhotoShop 6 that repeated visits to Lab from CMYK
gradually degrades the
colour so that after 25 transformations you are almost down to a grey
image. This does not happen in version 5.5.>>
This will depend on the definition of CMYK in Color Settings, not on the
version of Photoshop used. I showed similar results in my book on Photoshop 3.
>>This has some implications for those of us who convert to Lab mode to do
some sharpening if carefully crafted colours are messed about with!>>
If you're in CMYK already and the only thing you need LAB for is to
sharpen, then I'd recommend placing the CMYK document on a layer, disabling
the yellow channel in the Channels palette, sharpening the other three,
then changing the layer mode to Luminosity. This is likely to give as good
a result as a direct sharpen in LAB.
Dan Margulis------------------
From: Chris Murphy, INTERNET:lists@colorremedies.com
Date: Mon, Apr 23, 2001, 11:04 AM
RE: Re: [colortheory] Lab Conversion in 6.0

Converting to and from Lab has never been a damage free process. There
are always quantization errors. Not to mention if you don't have the
exact same separation information set as the CMYK working space (as when
the image was first converted to CMYK), the separation will be different
(you can have value changes of 30 points, especially in black)
On one hand I'm surprised by the idea an image would be nearly gray after
25 conversions in Photoshop 6, and this would be substantially different
in Photoshop 5.5; on the other hand, 25 conversions is too many
conversions, regardless. You need to convert to Lab and make appropriate
adjustments and once you're finished (i.e. you have no more Lab
adjustments to make) then go back to CMYK. Going back and forth that many
times isn't a good idea.
You might go into Color Settings, click on the advanced checked box, and
find the Dither option and turn it off. What's could be happening is
you're getting additional fine noise every single time you convert your
image. It should be a smart noise so I'd be somewhat surprised that this would cause desaturation in only 25 conversions - but I've never
converted a single image 25 times even for fun let alone on a real world
image.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932------------------
From: Chris Murphy, INTERNET:lists@colorremedies.com
Date: Mon, Apr 23, 2001, 12:03 PM
RE: Re: [colortheory] Lab Conversion in 6.0

>RGB>LAB>RGB is damage free, but CMYK>LAB>CMYK is not.
I disagree. If you start out with all of the same spaces for RGB and
CMYK, and use only those spaces - then convert to and from Lab, you will
get some quantization errors with both.
I see the same amount of quantization in RGB and CMYK. The biggest change
in a CMYK to Lab to CMYK conversion isn't the quantization, but when the
basis for separating the Lab file back to CMYK is different than the
basis for the initial separation that got you the CMYK image in the first
place.
So if you mean "damage" as in substantial change in values (while
colorimetry remains mostly the same), then this would occur much more
with CMYK than RGB.

Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 11:30 AM
RE: Re: [colortheory] Lab Conversion in 6.0
on 4/23/01 9:12 AM, Dan Margulis at 76270.1033@compuserve.com wrote:
> RGB>LAB>RGB is damage free
You1re not serious are you Dan?
Take an RGB file. Duplicate it. Do an RGB to LAB to RGB conversion and
subtract the two. You can turn on or off the 8 bit dither. When you subtract
the two and create a new document and look at the Histogram in Levels, you
will see there certainly is data loss and a change. Move the sliders of the
Levels Histogram over and you1ll see the effects of what differences between
the two files you produced. Are you saying this isn1t data loss?
Andrew Rodney ------------------
From: "Jerry L. P'Simer", INTERNET:jpsimer@twmi.rr.com
Date: Mon, Apr 23, 2001, 7:45 PM
RE: Re: [colortheory] Lab Conversion in 6.0> Am I missing something?
>
> I have always thought that moving from either CMYK or RGB to Lab and back
> was a damage free process, that is, you would end up with the same color
> co-ordinates when you arrived back from Lab mode. I have noticed with
> PhotoShop 6 that repeated visits to Lab from CMYK gradually degrades the
> colour so that after 25 transformations you are almost down to a grey image.
> This does not happen in version 5.5. This has some implications for those of
> us who convert to Lab mode to do some sharpening if carefully crafted
> colours are messed about with!
Converting From CMYK to any other color space and back to CMYK is always risky
and should be avoided. Especially for mere sharpening purposes. I will
occasionally convert from CMYK to LAB for color cast removal if I am having
problems doing so in CMYK. However, I will first duplicate the file convert to
LAB, correct color, convert back to CMYK and then place the corrected file on
top of the original CMYK and change the blending mode to color. This method
will keep the integrity of my original seperation.
Jerry P'Simer------------------
From: "Jerry L. P'Simer", INTERNET:jpsimer@twmi.rr.com
Date: Mon, Apr 23, 2001, 7:28 PM
RE: Re: [colortheory] Lab Conversion in 6.0

Andrew Rodney wrote:
>
> > RGB>LAB>RGB is damage free
>
> You1re not serious are you Dan?
>
> Take an RGB file. Duplicate it. Do an RGB to LAB to RGB conversion and
> subtract the two. You can turn on or off the 8 bit dither. When you subtract
> the two and create a new document and look at the Histogram in Levels, you
> will see there certainly is data loss and a change. Move the sliders of the
> Levels Histogram over and you1ll see the effects of what differences between
> the two files you produced. Are you saying this isn1t data loss.
Enlighten me, How do you subtract the two? Also, to what end? I happen to agree
with Dan. I have done multiple conversions between LAB and RGB and being the
mere mortal that I am, I can not detect a difference between the files. Since
my destination is always print (litho), I highly doubt that any human would
notice even the slightest amount of data loss (using there own eyes) between
and original RGB to CMYK conversion vs an RGB to LAB to RGB to LAB to RGB to
CMYK providing the same conversion methods are used.
Jerry P'Simer
-------------------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Mon, Apr 23, 2001, 7:45 PM
RE: Re: [colortheory] Lab Conversion in 6.0

Andrew Rodney writes,
>>Take an RGB file. Duplicate it. Do an RGB to LAB to RGB conversion and
subtract the two. You can turn on or off the 8 bit dither. When you
subtract
the two and create a new document and look at the Histogram in Levels, you
will see there certainly is data loss and a change. Move the sliders of the
Levels Histogram over and you1ll see the effects of what differences
between
the two files you produced. Are you saying this isn1t data loss?>>
Not only would I say this, but so would anyone else who has ever taken even
an elementary statistics course. It has long been my contention that
including the histogram function in Photoshop does more harm than good,
because (as here) people without a math background misinterpret it and draw
goofy conclusions.
Chris Murphy writes,
>>I see the same amount of quantization in RGB and CMYK.>>
Don't look at the histogram, look at the image.
>>The biggest change in a CMYK to Lab to CMYK conversion isn't the
quantization, but when the
basis for separating the Lab file back to CMYK is different than the basis
for the initial separation that got you the CMYK image in the first
place.>>
That would certainly cause a problem right away, but even without that, CMYK>LAB>CMYK has a small loss associated with it, not enough to get all agitated about, but enough to avoid making that conversion just for the sport of it. RGB>LAB>RGB you can do all day long.
>>So if you mean "damage" as in substantial change in values (while
colorimetry remains mostly the same), then this would occur much more with CMYK than RGB.>>
By "damage" I mean that it makes the image more difficult to work with,
lower in quality, or requires some kind of later countercorrection. That is
what happens if we go CMYK>LAB>CMYK, albeit to a very minor extent. To see
whether the effect is there, Mike did exactly the right thing: he did the
conversion 25 times in a row, and saw that the image was much the worse for
wear.
If, however, one goes RGB>LAB>RGB 25 times in a row, there is no such damage--the image is in every way, under every conceivable circumstance, equal in quality to the original. I could explain statistically why this is so, but what's the use? One can see it with one's own eyes, whether one understands the concepts of standard deviation and range of uncertainty or
not.
Dan Margulis
------------------------------
From: INTERNET:pfigen@keyway.net, INTERNET:pfigen@keyway.net
Date: Mon, Apr 23, 2001, 7:47 PM
RE: Re: [colortheory] Lab Conversion in 6.0

>
> > > RGB>LAB>RGB is damage free
> >
> > You1re not serious are you Dan?
> >
> > Take an RGB file. Duplicate it. Do an RGB to LAB to RGB conversion and
> > subtract the two. You can turn on or off the 8 bit dither. When you subtract
> > the two and create a new document and look at the Histogram in Levels, you
> > will see there certainly is data loss and a change. Move the sliders of the
> > Levels Histogram over and you1ll see the effects of what differences between
> > the two files you produced. Are you saying this isn1t data loss.
>
Didn't you two go at this a couple of years ago and come to the conclusion that
yes, there is some data loss, but for all practical purposes, it doesn't affect
the image. The simple fact is that a single trip to Lab isn't going to hurt your
image enough to see, and if you need to use Lab to do a correction that can only
be done there, the image will be better off for it, even if it IS minus a couple
of bits.
The last time I checked, I shot pictures of people and products and landscapes,
but I've never in my life photographed a Histogram.
Peter Figen
------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 8:15 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 5:42 PM, Dan Margulis at 76270.1033@compuserve.com wrote:
> Not only would I say this, but so would anyone else who has ever taken even
> an elementary statistics course. It has long been my contention that
> including the histogram function in Photoshop does more harm than good,
> because (as here) people without a math background misinterpret it and draw
> goofy conclusions.
>
You are missing the point. The Histogram doesn1t do anything but allow you
to see that the file has absolutely undergone a change with the mode change
and there is data loss, the file has been altered. I can actually SEE the
resulting calculation (data loss) without even having to go into levels and
mess with the Histogram. But altering the histogram makes seeing the effect
easier.
> Don't look at the histogram, look at the image.
>
This is nonsense Dan. JPEG at 10:1 or less is visually lossless yet none the
less, the fact remains that there IS loss. It doesn1t matter if you can see
it or not because latter in a files life, it may undergo another JPEG
compression or another mode change and undergo MORE data loss. Eventually it
will show. But that1s not the point! You stated that RGB to Lab undergoes no
data loss. That1s completely untrue. Now you want to bring up the fact you
can1t see that so there is no data loss? Please be clear and accurate.

> By "damage" I mean that it makes the image more difficult to work with,
> lower in quality, or requires some kind of later countercorrection.
>
Ah, I see, the Margulis definition of no data loss. Is that no data loss now
or in the future if someone attempts 3 more mode changes? Define 3more
difficult to work with? Difficult for Dan Margulis or the average Photoshop
user? We both know there is a HUGE difference in those two groups as far as
difficulty is concerned.
> If, however, one goes RGB>LAB>RGB 25 times in a row, there is no such
> damage--the image is in every way, under every conceivable circumstance,
> equal in quality to the original.
>
So where do you draw the line? Can you admit that a file could undergo such
mode changes multiple times in it1s life? Could someone open the file a year
latter and do yet another mode change but after the last guy JPEGed the
file? And I forgot to mention, I need a 302 print off a Lightjet which is a
heck of a lot more demanding on a file than a halftone dot to a press. You
don1t suppose anyone would ever output the file to such an abnormal output
device do you? You bet they would!Andrew Rodney --------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 8:10 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 5:48 PM, Peter Figen at pfigen@keyway.net wrote:
> Didn't you two go at this a couple of years ago and come to the conclusion
> that
> yes, there is some data loss, but for all practical purposes, it doesn't
> affect
> the image.
>
Once, to a halftone dot? Probably not. But what if it happens a few times?
What if the file is going out to a film recorder. What if the file wasn1t
scanned at the size we really need, we can1t rescan and we need to rez up
the file to a really good contone device like a LightJet? Do you suppose
that this conversion could produce an adverse effect on the output? I do.
Plus WHY are we doing the conversion in the first place? Why are we talking
a file with perhaps a few million colors into a HUGE colorspace and back
again? But the bottom line is, there IS data loss. Whether you can see it or
not isn1t the issue here.
Andrew Rodney
-----------------------From: INTERNET:pfigen@keyway.net,
Date: Mon, Apr 23, 2001, 8:16 PM
RE: Re: [colortheory] Lab Conversion in 6.0

> But the bottom line is, there IS data loss. Whether you can see it or
> not isnit the issue here.
If you can't see it, then there's no issue.
------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 8:20 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 5:27 PM, Jerry L. P'Simer at jpsimer@twmi.rr.com wrote:
> Enlighten me, How do you subtract the two? Also, to what end?
>
I know of at least three ways to do this in Photoshop (and there is probably
more). Here1s just one:
1. Open your RGB file
2. Duplicate the file (Image->Duplicate). Name it 3This will be damaged2
3. Take that duplicated file and convert to LAB then back to RGB.
4. Select 3Calculations2 (Image->Calculations2). In the dialog that appears
make sure one file is selected at the top as Source 1 (your original file),
the 2nd duplicate file is below (Source 2). In blending select 3Subtract2
and at the very bottom, it1s usually best to select 3New Document2 for the
result then hit OK.
5. In the new file you have subtracted one file from the other. IF the two
were identical, the result would be zero. The file would be absolutely
black. But if you open the new document and check Levels (Command L) you
will see that there is data all shoved over to the left side. Move the white
input slider all the way over to the left to where you start to see
something on the Histogram. Now you can see all the pixels that were altered
in the mode change. This is data loss!
> I have done multiple conversions between LAB and RGB and being the
> mere mortal that I am, I can not detect a difference between the files. Since
> my destination is always print (litho), I highly doubt that any human would
> notice even the slightest amount of data loss (using there own eyes) between
> and original RGB to CMYK conversion vs an RGB to LAB to RGB to LAB to RGB to
> CMYK providing the same conversion methods are used.
>
That1s not the point. The point is there IS data loss. You may end up having
to output the file to a very high quality contone device and you might see
the difference. Then again you might not. Point is, deluding yourself into
thinking there is no loss is like deciding to JPEG your files and assuming
that since the conversion is visually lossless, you can do this a multitude
of times with no penalty.
FWIW, I often archive files as JPEG. But I understand what1s happening here.
I understand there IS data loss. This list is supposedly called 3Color
Theory2 so are we going to be accurate about what is happening here or just
duck under the blankets and say 3well if you can1t see it, there is no data
loss2? Let1s be clear and accurate here. Yes, there is data loss and you
don1t want to do this kind of conversion a lot but for all practical
purposes, you will not see the data loss on MOST output devices. What1s so
hard about saying that? But Dan said (and you believe) that doing an RGB to
LAB to RGB conversion causes no data loss but somehow doing a CMYK to LAB to
CMYK is a bit worse. I say they are both equally worthy of being called
3data loss2. Some would say semantics. I say accuracy.
Andrew Rodney
------------------
From: Chris Murphy, INTERNET:lists@colorremedies.com
Date: Mon, Apr 23, 2001, 8:24 PM
RE: Re: [colortheory] Lab Conversion in 6.0
>
>>>I see the same amount of quantization in RGB and CMYK.>>
>
>Don't look at the histogram, look at the image.
yeah i haven't even looked at the histogram. I've only looked at the
image and the info palette, before and after.
>That would certainly cause a problem right away, but even without that,
>CMYK>LAB>CMYK has a small loss associated with it, not enough to get all
>agitated about, but enough to avoid making that conversion just for the
>sport of it. RGB>LAB>RGB you can do all day long.
Huh uh - I get small, nearly insignificant quantization with either
RGB-Lab-RGB or CMYK-Lab-CMYK.>By "damage" I mean that it makes the image more difficult to work with,
>lower in quality, or requires some kind of later countercorrection.
From that point of view I don't see it with either method as long as I
only do a few conversions. Why I'd do more than three is beyond me.
> Mike did exactly the right thing: he did the
>conversion 25 times in a row, and saw that the image was much the worse for
>wear.
OK when I have a spare half hour in my life to contribute to the cause,
I'll do 25 conversions with both RGB and CMYk to and from Lab and see
which one changes the most. I expect them to be the same and if they
aren't I don't have a technical explanation because theoretically the
quantization should be the same. Number of channels has nothing to do with it.Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
------------------
From: "Jerry L. P'Simer", INTERNET:jpsimer@twmi.rr.com
Date: Mon, Apr 23, 2001, 8:52 PM
RE: Re: [colortheory] Lab Conversion in 6.0

Andrew Rodney wrote:
> Some would say semantics. I say accuracy.
I say hogwash. Since most of us would not convert more than two or three times at most (excluding the
JPEG file format issues), I still think it is safe and accurate to say that the conversion from RGB to LAB and
back is virtually lossless.
Jerry P'Simer
------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 8:56 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 6:47 PM, Jerry L. P'Simer at jpsimer@twmi.rr.com wrote:
>> I say hogwash. Since most of us would not convert more than two or three
>> times at most (excluding the JPEG file format issues), I still think it is
>> safe and accurate to say that the conversion from RGB to LAB and back is
>> virtually lossless.
You can say hogwash and ignore the data loss but can you really guarantee
the file will NEVER undergo any other further data loss and I will never see
the effect to any output device in the future? I think it1s interesting that
now your comments are 3virtually lossless2 not lossless. I sense you may not
be sure...
Andrew Rodney
------------------
From: "Jerry L. P'Simer", INTERNET:jpsimer@twmi.rr.com
Date: Mon, Apr 23, 2001, 9:15 PM
RE: Re: [colortheory] Lab Conversion in 6.0
Andrew Rodney wrote:
> I think itis interesting that now your comments are ivirtually
> losslessi not lossless. I sense you may not be sure...
I am absolutely sure. I send files (CMYK) all over the country to a
multitude of printing conditions. I have been doing so for the past
fifteen years and I have yet to have any image fail for its intended
purpose. What happens to an image after it leaves my possession (if it is going to forgo any further conversions) would be beyond my control.
Jerry P'Simer------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Mon, Apr 23, 2001, 9:41 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/23/01 7:13 PM, Jerry L. P'Simer at jpsimer@twmi.rr.com wrote:
> What happens to an image after it leaves my possesion (if it is
> going to forgo any further conversions) would be beyond my control.
>
True indeed. But the damage could already be in place for the next user to
compound upon.
We 3damage2 our files all the time (unless we either work on a high bit file
or keep high bit archives in RGB). I1m not suggesting we do, or not do an
RGB to LAB to RGB conversion and then multiple tonal corrections on an 8 bit
file (I would suggest at least using adjustment layers so the multiple tonal
corrections are applied with a single convolution and thus reduces damage to
the file). Every correction * could * hose the file a small degree to the
point where banding will appear on output. So we have two choices here: We
can ignore the issue and pretend that any or all of these kinds of
corrections are lossless (which they are not) or we can be aware of the
possible consequences of such actions, be accurate in what we are doing to
our files and only do such corrections where there is a clear benefit. We
should also be aware that we don1t always have total control over our files,
know who else will be messing with them or know where such files may be
output in the future.
I1m suggesting safe computing (or retouching if you will) and I1m suggesting
we don1t fool ourselves in thinking that because we don1t see something
happening to our files, it1s not damaging them. The math is quite clear here
as I1ve illustrated with the calculation command. The original claim was
that an RGB to LAB to RGB conversion was lossless. That1s simply not the
case. I1m not interested in arguing how many pixels have to fit on the head
of a pin before someone will see damage on output. That1s simply not
possible with all the variables in the world. The conversion isn1t lossless
and at some point, it1s certainly possible that the effect can be seen on
output.
If you could apply any or all corrections with no data loss, even though you
couldn1t see the difference, would you?
What1s interesting is that I just created two output profiles from the same
spectral data. One was generated for 100% total ink limit, the other 320%.
Both appear identical when viewed in Photoshop on the composite channels. So
with that in mind (and without searching for the real story here and
checking the individual channels as I illustrated in a more advanced fashion
with calculations), would *could* be fooled into thinking that the two files
are the same. Clearly both files are not nor would the output the same.
Sometimes something that looks a certain way isn1t! To suggest that a file
has undergone NO damage or data loss because you can1t see it isn1t the most
savvy argument in favor of a lossless conversion. That has been my point
from the beginning.
Andrew Rodney
------------------
From: Mike Russell, INTERNET:mgr@zocalo.net
Date: Tue, Apr 24, 2001, 12:16 AM
RE: Re: [colortheory] Lab Conversion in 6.0> Am I missing something?
>
> I have always thought that moving from either CMYK or RGB to Lab and back
> was a damage free process, that is, you would end up with the same color
> co-ordinates when you arrived back from Lab mode. I have noticed with
> PhotoShop 6 that repeated visits to Lab from CMYK gradually degrades the
> colour so that after 25 transformations you are almost down to a grey image.
> This does not happen in version 5.5. This has some implications for those of
> us who convert to Lab mode to do some sharpening if carefully crafted
> colours are messed about with!
I suspect something unusual about your CMYK setup, or the engine, as I am able to do 25 cmyk<->rgb
conversions with definite changes, but not severe degradation of the image.
Long ago, I ran some tests to see how quickly image data degrades in response to repeated changing
of color modes. Inspired by this rather warm thread, I decided to recreate the test tonight for
fun. My test used rgb instead of Lab, however I think the results will be of interest.
For my original I used a 3 megapixel rgb image, red flowers against a green background, saved in rgb
format, and resized it down to about 1/4 its original resolution. CMYK conversions were done using
the PS4 default settings, and the ACE engine in PS6.0. Dithering was off, although it did not seem
to make much difference one way or the other.
In each case, I manipulated the original image, usually by converting it back and forth between
color spaces. Then I differenced the red channel of resulting image with that of the original, and
did a histogram of the resulting file. In all cases, except the 25 cycles of cmyk <-> lab, the mean
and median were within one point of one another, and the standard deviation was a reasonably
symmetrical gaussian.
Here are some of the results:
1cycle of rgb->cmyk->rgb median pixel change 15
5cycles of rgb->cmyk->rgb median pixel change 15
10 cycles of rgb->cmyk->rgb median pixel change 16
(5 cycles diffed with 10 cycles) median pixel change 1
1 cycle of rgb->lab->rgb median pixel change 15 (!)
1 cycle cmyk->lab->cmyk median pixel change 1
25 cycles cmyk->lab->cmyk median pixel change 1, std dev 5.7, max change 80
save as jpeg, quality 5 (36:1 compression) median pixel change 2
A couple of conclusions:
1) Most of the data change between rgb and cmyk occurs on the first conversion, when gamut clipping
happens, and subsequent changes result in little change in pixel data, limited to round off error
only. The areas with the least change tended to be at the edges where red flower met green
background, perhaps because pixels in these areas had less saturated color.
2) There appears to be little penalty even for repeated color space changes, however certain color
values appear to keep "walking" to an unbounded amount of change. In the case of my test image, the
walking color values were located at a relatively high contrast edge between a red flower and black
shadow. An image with a large number of such borders would see significant erosion of edges after
25 passed.
3) jpeg is pretty darn good, with even 32:1 compression, compared to most color space conversions.
Open questions - why such a large change for rgb->lab conversion? As I mentioned I had dither
turned off?
http://www.zocalo.net/~mgr
------------------
From: "Mike McNamee Compuserve", INTERNET:mikemcnamee@compuserve.com
Date: Tue, Apr 24, 2001, 3:53 AM
RE: [colortheory] Lab RGB etc

Good morning America! Thank you all for your prompt and thoughtful responses
to my query. Seeing as I have provoked such interest I am anxious to keep
the pot on the boil. Lets see if we can push the thing along a bit further.
Consider this conundrum if you will please.
Illustrator 8 was capable of holding both RGB and CMYK objects on the same
page (unlike version 9). This enables you to make a 100% cyan swatch and a
255 Red swatch alongside each other. If you then copy both these to the
clipboard, go to Photoshop 5.5, make a new file, ask for Lab mode and paste
pixels you get the swatches over almost intact as 255 Red (255R;9G;1B) and
100% Cyan (100C;1M;0;0). Transferring out of Lab mode into RGB degrades the
Cyan as it is out of RGB Gamut; Transferring into CMYK degrades the Red as
255 R is out of the CMYK Gamut. Both of these results are expected (in my
case I used Adobe 1998 for RGB and SWOP Coated for CMYK). However, if Lab is
the all embracing space why wont it hold on to both values as neither is
outside the boundaries of the CIE 1931 Space. The original definition of Lab
was The idea was to create a truly device independent color modelling
scheme that would preserve color values (hue, saturation, brightness)
Biendy, Monroy, Moody PhotoShop Channel Chops.
A couple of respondents thought that I was moving back and forth between
spaces 25 times as part of a routine manipulation. I was only following the
old fashioned engineering principle of pushing until it broke in the hope of
finding the root cause of the problem. In my innocence I expected, at the
very least, that it would progress to the nearest in-gamut color
co-ordinates and then stay put! I dont think that there are quantization
errors at issue here. PhotoShop uses 20 bits per channel in its CMS engine,
giving discrimination that is far beyond the errors (shifts) that you
observe as you move about the color spaces. I would also expect error
rounding to work in both direction (ie rounding up and down) it is a basic
engineering tenet that errors/tolerances should not be cumulative!
You may be wondering why this crazy English magazine editor is worrying
about all this well it all started out of curiosity while reviewing
PhotoShop version 6. I was interested in how the new CMS engine dealt with
color values at the extremities of the color spaces (eg 100% values in CMYK
and 255 values in RGB). But there is also a valid reason to work out what is
going on anyway. If you have set up a Pantone Process equivalent on a
Photoshop page you would rather like it to stay intact after an excursion
Lab to do some sharpening! By way of example if you take a colour of
10C100M50Y15K and transfer it to Lab then back to CMYK it comes back as
23C100M58Y9K. The pair have a Delta E Lab of 5.5; not a huge amount but
other mixes may misbehave even more. If you plot the values back to CIE 1931
you can see daylight between the points! These shifts seem too big to be
quantization or rounding errors. More important, colorimetry will show that
your starting Pantone equivalent has been changed to something that is not
even on he same swatch strip!
PhotoShop 6 does seem to behave differently in its transformation algorithms
to Photoshop 5 particularly in regard to the high magenta mixes (100%M or
255R255B) I think it is actually better - but it is different. I cant
decide if it is the new CMS engine or SWOP V2 or both. This is the kind of
stuff that keeps our press shops resolutely fixed on PhotoShop 4, they cant
do with colours flying off in what seem to be unpredictable ways is this
the same in the US?
Thanks for your continued interest.
Ps for Dan Margulis. Do you cover any of this stuff in Your V6 Book Dan, I
have been unable to obtain a review copy thus far in the UK?
------------------
From: INTERNET:samarsh@ozemail.com.au, INTERNET:samarsh@ozemail.com.au
Date: Tue, Apr 24, 2001, 5:29 AM
RE: [colortheory] A real world example of the RGB>LAB>RGB debate...

I have been following this thread with much interest.
I have to agree with the major consensus - no matter the colour mode, there is a change to
your data. In my tests, using 8 bpc files and Legacy RGB and ColorMatch RGB this was only
minimal and did not have a visible impact to the image in 90% of the real world tests.
But other users push the envelope more than my more traditional pre press use.
On another list, I helped a user of Adobe RGB with a rich outdoor sky shot on some sort of
neg and scanned in a film scanner. Outputs were to some larger gamut than press device,
which was fed RGB data of some flavour. I cant remember if this was Epson or some larger
gamut device.
This was not a RGB>CMYK issue - just sharpening via a LAB conversion with no curve tweaks.
I was very shocked at the effects of the simple mode change from RGB>LAB>RGB on APS4 and
5.5.
Here are the links so you can view the differences, and download and see for yourself:
http://members.ozemail.com.au/~samarsh/RGB.jpg
http://members.ozemail.com.au/~samarsh/LAB2RGB.jpg
(These untagged legacy RGB images can be considered AppleRGB if you want to convert
colours).
It does not matter that the sky is probably out of gamut for many, but not all devices, if
you were only after a luminosity preview/sharpen with no other special LAB tricks - then
this LAB mode change would require further edits and would be considered 'damaging'.
I think this is one of those exceptions to the general rule. But the harder you look - you
could probably find more real world examples.
As graphics becomes broader and more users use wider gamut working spaces and output - the
context of a discussion should be firmly established. What applies to traditional halftone
press printing might not apply to alternate devices.
My general conclusion on this whole debate is:
For sharpening, a luminosity fade and or blend is ideal. LAB is only entered for
chromacity noise reduction or other tricks which are better suited to the nature of truly
visible/editable split luminosity/colour.
Perhaps 'multichannel' is the only "safe" mode change. At least when the channels are
recombined the values or appearance have not changed.
Sincerely,
Stephen Marsh.
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Apr 24, 2001, 9:53 AM
RE: [colortheory] A real world example of the RGB>LAB>RGB debate...

Stephen writes,
>>I was very shocked at the effects of the simple mode change from
RGB>LAB>RGB on APS4 and
5.5. Here are the links so you can view the differences, and download and
see for yourself:>>
What seems to have happened here is that the file was intended to be Adobe
RGB, but during conversion to LAB it was assumed that it was an sRGB file.
That will, of course, hose all the colors. The possibility of such hijinks
is a major reason that many users avoid Adobe RGB.
Treating this as an Adobe RGB file, and converting RGB>LAB>RGB five times,
I get the normal result, no variation of any significance, quality-wise or
statistical.
Dan Margulis
P.S. If this file were properly converted to sRGB, this would be an example
of the kind of file that *wouldn't* convert well, because so much of it is close to the edge of the gamut. But sRGB>LAB>sRGB, although not lossless,
would be better than, for example, sRGB>Adobe RGB>sRGB.
------------------
From: Bob Smith, INTERNET:rmsmith@calpha.com
Date: Tue, Apr 24, 2001, 8:18 AM
RE: Re: [colortheory] Lab Conversion in 6.0

I think this debate about how much of a worry (if any) this is centers
around what happens to your images on down the line. Images prepped and
used for a specific purpose are of little worry. If you have to jump
through hoops to detect data inconsistencies... and can't actually see
them... then who cares. However, I think Andrew is right here. I know I go
to what some of you would consider unnecessary extremes to maintain data
integrity as far into the process as possible. I do a lot of my basic
editing on 16bit images, including RGB>LAB>RGB conversions. Doing this is
probably of no noticeable benefit at all in many (most?) work flows, but
I've seen too many of my images used in ways WAY beyond what was ever
intended with the file I delivered. No, I don't have any control over what
someone down the line does to my image, but it still affects me (I'm a
photographer) if the results look like hell. By delivering images with the
fewest possible unnecessary artifacts in each channel, I allow someone down
the line to butcher the image mercilessly ( and believe me, someone will!)
with the least possible ill effects. Making the image look correct is my
most important goal, but second is doing it in a way that preserves data
integrity to as high a degree as possible. Prepping images for final output
and prepping images that you're handing off to someone else for possible
further manipulation are two different kinds of work.
Bob SmithJerry L. P'Simer wrote:
> Andrew Rodney wrote:
>
>> I think itis interesting that now your comments are ivirtually
>> losslessi not lossless. I sense you may not be sure...
>
> I am absolutely sure. I send files (CMYK) all over the country to a
> multitude of printing conditions. I have been doing so for the past
> fifteen years and I have yet to have any image fail for its intended
> purpose.What happens to an image after it leaves my possesion (if it is
> going to forgo any further conversions) would be beyond my control.
------------------

From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Apr 24, 2001, 9:51 AM
RE: Re: [colortheory] Lab Conversion in 6.0

Chris writes,
>>From that point of view I don't see it with either method as long as I
only do a few conversions. Why I'd do more than three is beyond me.>>
It's beyond me as well, which is why I can't understand why anyone thinks
this thread is relevant to the real world. If there's no realistic loss in
a single or even two conversions...
>>OK when I have a spare half hour in my life to contribute to the cause,
I'll do 25 conversions with both RGB and CMYk to and from Lab and see
which one changes the most. I expect them to be the same and if they
aren't I don't have a technical explanation because theoretically the
quantization should be the same.>>
When you do this test, and discover that the CMYK version changes by far
the most, then you get to join the club. That is, you have discovered that
your theory appears to be disproved by the facts. So, you have to try to
work out what it is that's wrong about your theory. I'm sympathetic. This
happens to me all the time, this week in particular.
Dan Margulis
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Apr 24, 2001, 9:53 AM
RE: Re: [colortheory] Lab Conversion in 6.0

Peter writes,
>>If you can't see it, then there's no issue.>>
Correct, of course. This differentiates it from a JPEG save. Even at a high
quality level, one can easily identify the JPEGged file by examining each
channel at high magnification on the monitor, granted that there would be
little to no loss in print. But even after 25 RGB>LAB>RGB conversions, I'd
defy anybody to look at the channels under any magnification and tell which
was which.
But if there *were* a minuscule loss, who cares? Nobody takes a file into
LAB because their RGB was perfect. They go to LAB because they perceive a
problem with the file that can't be fixed easily elsewhere.
Dan Margulis
------------------
From: John Roushkolb, INTERNET:john@gathh.com
Date: Tue, Apr 24, 2001, 9:55 AM
RE: [colortheory] "Damage" v. "Data Loss"

One of the things I think is being missed here is the definition of
damage, at least as much as I see it.
I agree with BOTH Dan and Andrew on this one. There is definitely
data loss in any colorspace conversion. But when you look at the
results with respect to the final output device, damage is relative.
If the pic is going to press, the data loss threshold for damage is
much higher than if the pic is going to be upsized (super-sized?) for
a contone or other large output.
It would be nice to not have data loss, but it shouldn't stop us from
making the occasional foray between colorspaces if it is necessary to
fix a certain problem. Just keep in mind that there will be some
sort of data loss, and plan accordingly if that loss will be high
enough to cause "damage" to your final output piece.
--
John Roushkolb
Color Technician
Graphic Arts of Topeka, Inc.
785.354.8596
john@gathh.com
------------------
From: "Ron Bean", INTERNET:rbean@execpc.com
Date: Tue, Apr 24, 2001, 10:28 AM
RE: Re: [colortheory] Lab Conversion in 6.0

Just to add some perspective...
It's been pointed out here in the past that any *unplanned*
repurposing is a crapshoot anyway. If you're serious about
repurposing, you need to plan ahead.
In other words, there is a nonzero probability that the
unexpectedly repurposed image will look like crap anyway.
If you've taken an extra trip to LAB and back, then it will be
crap plus delta-crap, where delta is small because you only did
it once (not 25 times, which nobody does on a production image).
Whether that delta will turn out to be the straw that broke the
camel's back is really not predictable.
If this amount of uncertainty bothers you, why not save a copy of
the raw scan before you mess with it in the first place? And/or
an intermediate correction (probably before sharpening, since
the amount required will vary with the output device).
Does anyone actually do this?
I thought it was obvious that *any* correction does a nonzero
amount of damage to the data, in exchange for improving some
other aspect of the image. If the raw image *needs* correction,
then presumeably the tradeoff is worth it-- the alternative is to
print a substandard image, in order to save the data for some
hypothetical future use (unless you saved a copy of the raw data,
which nobody seems to have thought about in this thread).
The other question is whether there is a different way to correct
the image. Dan has a lot of sharpening tricks, so if you're going
to LAB just for that, see the appropriate chapter in his book.------------------
From: "shAf", INTERNET:michael@shaffer.net
Date: Tue, Apr 24, 2001, 11:15 AM
RE: RE: [colortheory] Lab Conversion in 6.0
Dan writes ...
> But if there *were* a minuscule loss, who cares?
> Nobody takes a file into LAB because their RGB was
> perfect. They go to LAB because they perceive a
> problem with the file that can't be fixed easily
> elsewhere.
I'll agree here if the RGB problem could be fixed with adjustments
made to 'a' or 'b' ... but many mistakenly believe the conversion is
necessary for working with 'L' ... simply not true.
Also, ... less I missed something ... the original post, with regard
to artifacts of the Lab conversion (and back), was with respect to
PS5.x. I had noticed this as well, and the artifacts are not
insignificant when working with wide gamut color spaces which approach
the Lab boundries. For example, if using PhotoProRGB, saturated blue
is definitely smashed with this conversion ... even if working with
16bits. It is also true subsequent conversions, do not "smash" blue
any more ... probably because what RGB values which have been smashed
is now accommodated by the conversion and need not be smashed again.
Regarding PS6, these effects are significantly reduced and I haven't
experimented enough to realize why.
shAf :o)
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Apr 24, 2001, 12:48 PM
RE: Re: [colortheory] Lab Conversion in 6.0

Bob Smith writes,
>>I know I go to what some of you would consider unnecessary extremes to
maintain data integrity as far into the process as possible. I do a lot of
my basic editing on 16bit images, including RGB>LAB>RGB conversions. Doing
this is probably of no noticeable benefit at all in many (most?) work
flows, but I've seen too many of my images used in ways WAY beyond what was
ever intended with the file I delivered.>>
For the record, I'd like to repeat a request to advocates of this workflow.
I acknowledge that editing 16-bit images is theoretically superior.
However, I've not seen any real-world cases where there was any advantage
whatever. I have done some weird things to 16-bit files, and in every
instance I got no better quality than if I had converted them to 8-bit
first and done the same things.
Therefore, if anybody can give me a counter-example, I would very much
appreciate it. That is, if anyone has some 16-bit images that they claim
would give better results under any conceivable chain of events leading to
their final conversion to 8-bit, as opposed to just converting to 8-bit in
the first place, I'd love to hear from you and make arrangements to get
hold of the images.
Dan Margulis
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Tue, Apr 24, 2001, 12:48 PM
RE: [colortheory] "Damage" v. "Data Loss"
John Roushkolb writes,
>>There is definitely data loss in any colorspace conversion. But when you
look at the
results with respect to the final output device, damage is relative.<<
No. There is definitely *variation* in any colorspace conversion. Variation is not necessarily bad, unless the original is absolutely perfect. If, for example, the original is a Photoshop-generated gradient, every pixel is perfect. In this case, any conversion will cause damage, or, if you prefer, data loss.
Photographic images, however, aren't perfect, because any method of
scanning or digital capture will have introduced undesirable variation.
It's entirely possible that a later conversion may compensate for some of
this variation and therefore be more faithful in some respects to the
original scene than the first capture was. This is the key statistical
point that some of our friends who consider themselves theoreticians miss.
It's like anything else in life. If a thing is perfect, it can't be
improved, only made worse. If a thing is *not* perfect, an alternate
version may be equivalent, worse--or better.
If somebody wants to demonstrate that a certain method of conversion damages files (or causes data loss, if you prefer) that can be done in oneof three ways. One, it can be done statistically by showing that the
variation goes beyond the range of uncertainty in the original. Two, it can
be done logically, by repeating the conversion many times and showing that
an undesirable effect is magnified. Third, it can be done perceptually, by
carefully examining the image before and after conversion to see if there's
anything at all that would cause a human observer to favor one version over
the other.
But if none of these three things can be shown, then there is no damage,
and there is no data loss.
Dan Margulis
------------------
From: "shAf", INTERNET:michael@shaffer.net
Date: Tue, Apr 24, 2001, 1:21 PM
RE: RE: [colortheory] "Damage" v. "Data Loss"Dan writes ...
> No. There is definitely *variation* in any colorspace
> conversion. Variation is not necessarily bad, unless
> the original is absolutely perfect. ...
>
> Photographic images, however, aren't perfect, ...
You have a point when we all realize 8bit adjustment artifacts cannot
usually be pointed at, ... but as many photographs could possibly
approach your definition of "perfection", there are those of us who
would choose to recognize "bad habits" or "bad practice" ... and
generally recognize working with 16bit tools is a "better practice"
before converting to 8-bit working spaces.> If somebody wants to demonstrate that a certain method
> of conversion damages files (or causes data loss), that
> can be done in one of three ways. One, [...] Two, it can
> be done logically, by repeating the conversion many times
> and showing that an undesirable effect is magnified. ...
Let me pose an example, which I originally posted when PS5 first
emerged with its ability for embedding working space profiles, and
touted profile conversions as "the method" for exchanging files
amongst different computers, as well as working with device spaces ...
Assume a natual photograph with some smooth gradients ... also assume
a graphic artist uses a Mac and prefers to work in ColormatchRGB ...
also assume her boss insists on previewing and editting, but he/she
has a wintel and prefers to work in AdobeRGB. How many times do your
really believe these two co-workers can exchange the same file without
the gradients exhibiting some significant (recognizable)
posterization, if each converts upon opening, edits and then saves???
(recognize, of course, this example was in the context of PS5 ... now
that PS6 adds noise when converting, the image will not become
posterized ... but how much noise would we want introduced???)
shAf :o)
------------------
From: Chris Murphy, INTERNET:lists@colorremedies.com
Date: Tue, Apr 24, 2001, 8:04 PM
RE: Re: [colortheory] Lab RGB etc
>This enables you to make a 100% cyan swatch and a
>255 Red swatch alongside each other. If you then copy both these to the
>clipboard, go to Photoshop 5.5, make a new file, ask for Lab mode and paste
>pixels you get the swatches over almost intact as 255 Red (255R;9G;1B) and
>100% Cyan (100C;1M;0;0).
To my knowledge, the Mac OS and Windows clipboards only support RGB. So
you only get good copies within the same application. Now may Adobe has
some way to do better copy/paste between its own applications - I don't
know. But I suspect that it's not capable of doing a perfect job when
copy/pasting two objects in two different color spaces. If this were
going through the Mac OS copy mechanism, I would expect there to be an
error at least as much as this. So it has nothing to do with the gamut of
Lab (being essentially gamutless).
>However, if Lab is
>the all embracing space why wont it hold on to both values as neither is
>outside the boundaries of the CIE 1931 Space. The original definition of Lab
>was The idea was to create a truly device independent color modelling
>scheme that would preserve color values (hue, saturation, brightness)
>Biedny, Monroy, Moody PhotoShop Channel Chops.
a.) CIE XYZ was developed in 1931. CIE L*a*b* was developed in, I
believe, 1976.
b.) Lab itself is device independent. RGB and CMYK are not. In order to
get the same RGB values you started out with you need the same basis
going in and coming out. Therefore conversions to and from Lab are only
as good as the profiles for the RGB and CMYK spaces you are converting in
and out of.
When you create a color of 50c, 10m, 80y, 40k - what is the basis for the
black value? What is the black generation amount? What formula was used
to compute each channel? If you convert this into Lab, the K channel is
reintegrated. It's completely lost in Lab. It's impossible to get the
exact same four values back out without knowing the precise method by
which you arrived at the original values to begin with and having a
profile built to use that separation method. This is the same in
Photoshop 6 as it is in 2.5.>A couple of respondents thought that I was moving back and forth between
>spaces 25 times as part of a routine manipulation. I was only following the
>old fashioned engineering principle of pushing until it broke in the hope of
>finding the root cause of the problem. In my innocence I expected, at the
>very least, that it would progress to the nearest in-gamut color
>co-ordinates and then stay put! I dont think that there are quantization
>errors at issue here.
It's possible that this is profile specific or CMM specific, or both and
it's just a problematic profile. Or perhaps you've found a bug in
something.
>I would also expect error
>rounding to work in both direction (ie rounding up and down) it is a basic
>engineering tenet that errors/tolerances should not be cumulative!
Unless the rendering intent is either saturation or perceptual. In the
case of perceptual rendering, it's possible to compress the image farther
into the destination space's gamut until you end up with something that
has no color (theoretically, I've never tried it). These conversions must
be done with either absolute colorimetric or relative colorimetric
rendering.
> If you have set up a Pantone Process equivalent on a
>Photoshop page you would rather like it to stay intact after an excursion
>Lab to do some sharpening!
Well it's not going to. That's not what Photoshop was designed for. You
don't get 1:1 conversions of CMYK values. It just isn't possible right
now.
> By way of example if you take a colour of
>10C100M50Y15K and transfer it to Lab then back to CMYK it comes back as
>23C100M58Y9K.
>This is the kind of
>stuff that keeps our press shops resolutely fixed on PhotoShop 4, they cant
>do with colours flying off in what seem to be unpredictable ways
With default settings in Photoshop 4 you value above of 10c,100m,50y,15k
converts into Lab and then back into CMYK as 20c,100m,56y,5k. It has
nothing to do with Photoshop 4 versus Photoshop 5 or 6.
When I take 10C100M50Y15K in Photoshop 6 with default settings and
convert into Lab and then back to CMYK, I end up with 20c,100m,57y,6k.
I computed predicted delta E's for how the color changes during this
conversion. For Photoshop 4 it's 1.73, and for Photoshop 6 it's 2.Chris Murphy
Color Remedies (tm)
Boulder, CO
303-415-9932
------------------
From: Dave Badger, INTERNET:dbadge@worldnet.att.net
Date: Tue, Apr 24, 2001, 9:36 PM
RE: Re: [colortheory] Lab Conversion in 6.0
on 4/23/01 8:19 PM, Andrew Rodney at andrew@digitaldog.net wrote:
> Yes, there is data loss and you
> don1t want to do this kind of conversion a lot but for all practical
> purposes, you will not see the data loss on MOST output devices.
What about color management conversions? Are not CMM's doing the same
RGB>LAB>RGB as you've been discussing? This would lead me to believe that as
files are passed off from one color space to another (i.e. Convert to
working space, etc) that small data losses are building up as the file goes
through it's various CM transformations.
Dave Badger
------------------
From: Bob Tyson, INTERNET:bobicho@earthlink.net
Date: Tue, Apr 24, 2001, 8:15 PM
RE: Re: [colortheory] Lab Conversion in 6.0
Dan,
Does your question include 16 or 14-bit scans from transparent
materials with long scales, which may require strong curve
adjustments, "stretching" or "compressing" some parts of the scale
along the way? I can't pick up an example to send at the moment but
in my work from b&w negs having 16-bit to start helps with what's
going on in the ends of the scale. I conver to 8-bit after that
preliminary adjustment, which sometimes is pretty severe.
After that point, when the full scale is "comfortably" contained in
the 8-bit file, I can't see any advantage to 16-bit, either.
Bob Tyson.
>
>Therefore, if anybody can give me a counter-example, I would very much
>appreciate it. That is, if anyone has some 16-bit images that they claim
>would give better results under any conceivable chain of events leading to
>their final conversion to 8-bit, as opposed to just converting to 8-bit in
>the first place, I'd love to hear from you and make arrangements to get
>hold of the images.
>
>Dan Margulis
--
Bob Tyson
Bob Tyson -//- photographs
http://home.earthlink.net/~bobicho/bperspho.html
------------------
From: Andrew Rodney, INTERNET:andrew@digitaldog.net
Date: Tue, Apr 24, 2001, 10:26 PM
RE: Re: [colortheory] Lab Conversion in 6.0

on 4/24/01 7:37 PM, Dave Badger at dbadge@worldnet.att.net wrote:
> What about color management conversions? Are not CMM's doing the same
> RGB>LAB>RGB as you've been discussing? This would lead me to believe that as
> files are passed off from one color space to another (i.e. Convert to
> working space, etc) that small data losses are building up as the file goes
> through it's various CM transformations.
>
Absolutely. It1s a colorspace conversion. But Photoshop does all the
conversions with 21 bit precision. Still, there are quantization errors. So doing conversions with profiles should be kept to a minimum. Ideally this
will only happen twice; tag input data with source profile for first
conversion to Working Space then convert from Working Space to output space.
Andrew Rodney
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Wed, Apr 25, 2001, 9:03 AM
RE: [colortheory] Lab RGB etc

Mike McNamee writes,
>>Illustrator 8 was capable of holding both RGB and CMYK objects on the
same
page (unlike version 9). This enables you to make a 100% cyan swatch and a
255 Red swatch alongside each other. If you then copy both these to the
clipboard, go to Photoshop 5.5, make a new file, ask for Lab mode and paste
pixels you get the swatches over almost intact as 255 Red (255R;9G;1B) and
100% Cyan (100C;1M;0;0). Transferring out of Lab mode into RGB degrades the
Cyan as it is out of RGB Gamut; Transferring into CMYK degrades the Red as
255 R is out of the CMYK Gamut. Both of these results are expected (in my
case I used Adobe 1998 for RGB and SWOP Coated for CMYK). However, if Lab
is
the all embracing space why wont it hold on to both values as neither is
outside the boundaries of the CIE 1931 Space.>>
LAB is certainly capable of producing 255r0g0b. Why it is not doing so in
this case presumably is some Illustrator 8 peculiarity. As for 100c1m, this
is one of those annoying color management problems that should really be
handled better. From the pure theory point of view if you get 1m extra in
any color this is statistically reasonable; if a picture has an area of
57c22m that becomes 57c23m after reconversion there's no way to tell which
version is more accurate. If, however, an area is 100c, it's a dead
certainty that the file creator put it in manually and *wants* 100c, not
100c1m.
This shows up in an even worse way when, under certain circumstances, a
conversion can change 255r255g255b, a pure white, into 1c1m1y1k. This is a
major fault in today's color management technology. Chris Murphy has been
particularly outspoken on the need to correct this.
>>A couple of respondents thought that I was moving back and forth between
spaces 25 times as part of a routine manipulation. I was only following the
old fashioned engineering principle of pushing until it broke in the hope
of
finding the root cause of the problem. In my innocence I expected, at the
very least, that it would progress to the nearest in-gamut color
co-ordinates and then stay put! I dont think that there are quantization
errors at issue here. PhotoShop uses 20 bits per channel in its CMS engine,
giving discrimination that is far beyond the errors (shifts) that you
observe as you move about the color spaces. I would also expect error
rounding to work in both direction (ie rounding up and down) it is a basic
engineering tenet that errors/tolerances should not be cumulative!>>
Your testing approach is correct and scientifically valid.
>>By way of example if you take a colour of 10C100M50Y15K and transfer it
to Lab then back to CMYK it comes back as 23C100M58Y9K.>>
This is normal behavior. CMYK colors can be expressed in many different
ways depending upon how much black ink is specified. Once the file has gone
to LAB, Photoshop no longer knows how much black ink it used to have, and
when it's reconverted to CMYK it will use the black generation specified in
Color Settings.
>>PhotoShop 6 does seem to behave differently in its transformation
algorithms to Photoshop 5 particularly in regard to the high magenta mixes
(100%M or 255R255B) I think it is actually better - but it is different. I
cant decide if it is the new CMS engine or SWOP V2 or both. This is the
kind of stuff that keeps our press shops resolutely fixed on PhotoShop 4,
they cant do with colours flying off in what seem to be unpredictable ways
is this the same in the US?>>
I don't think that this particularly bothers them. They stick with the
older ways because there is less possibility for calamitous error, such as afflicted the file reported by Stephen elsewhere.
>>Ps for Dan Margulis. Do you cover any of this stuff in Your V6 Book?>>
I did at one time, but it's no longer worth the space. In the mid-90s when I was first publishing details on how to use LAB, various RGB-centric forces announced that LAB was unusable because of massive "data loss" and "proved" it by means of converting grayscale gradients from RGB to LAB with predictably poor results. A number of people believed this pap at the time, and therefore in one of my books I showed before-and-after images that had been converted RGB>LAB>RGB 75 times and indicated that I could not tell which was the original by inspection even at high magnification on the monitor.
At that time, virtually nobody used LAB in color correction. Now, it's well entrenched in the professional community. The people who adopted it obviously feel that the damage--if any--is minimal in comparison to the benefits of working in LAB for particular images. So, I believe that it's widely recognized among serious users that the "data loss" alarmism wasn't justified, and conclude that no discussion of it is necessary in my current books.
Dan Margulis
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Wed, Apr 25, 2001, 9:02 AM
RE: RE: [colortheory] "Damage" v. "Data Loss"
Shaf writes,
>>there are those of us who would choose to recognize "bad habits" or "bad
practice" ... and generally recognize working with 16bit tools is a "better
practice" before converting to 8-bit working spaces.>>
A lot of things have been "generally recognized" by color pundits, and have proven over time to be baloney.
I'm open to the idea that it may be a better practice, but I've tried it
out with a lot of images and am obliged to say that nothing I have seen so
far indicates that it does anything but eat disk space.
This is why I have asked several times over several years for anybody who
can provide actual 16-bit images and histories of what was done with them
that would *not* have been equally effectively done in 8-bit, to do so. I'm
happy to endorse the practice if somebody can demonstrate to me that it
actually helps.
>>Assume a natual photograph with some smooth gradients ... also assume a
graphic artist uses a Mac and prefers to work in ColormatchRGB ...also
assume her boss insists on previewing and editting, but he/she has a wintel
and prefers to work in AdobeRGB. How many times do your really believe
these two co-workers can exchange the same file without the gradients
exhibiting some significant (recognizable) posterization, if each converts
upon opening, edits and then saves??? (recognize, of course, this example
was in the context of PS5 ...>>
You appear to be confusing me with someone else. When PS5 came out I condemned this type of workflow in no very uncertain terms. That saddling novice users with their own private workspaces to which they would convert incoming files on the fly was "genius" and "brilliant" is an idea expressed by other parties on this list.
Dan Margulis
------------------
From: "shAf", INTERNET:michael@shaffer.net
Date: Wed, Apr 25, 2001, 10:49 AM
RE: RE: [colortheory] "Damage" v. "Data Loss"

Dan writes ...
> ...
> I'm open to the idea that it [16bit] may be a better
> practice, but I've tried it out with a lot of images
> and am obliged to say that nothing I have seen so
> far indicates that it does anything but eat disk space.
> ...
I would agree, generally speaking, a well exposed and normal image does not require highbit tools. However, I have been confronted with
a backlit and underexposed subject, which offered only 20 shades to
play with in 8bit space. If the desire is to add contrast and
brighten this part of the image, I'd surely end up with posterization.
However, if I scan into highbit space, the number of shades increased
to near 100, and now I have something to work with.> >>Assume a natual photograph with some smooth
> gradients ... also assume a graphic artist uses a Mac
> and prefers to work in ColormatchRGB ...also
> assume her boss insists on previewing and editting, but
> he/she has a wintel and prefers to work in AdobeRGB.
> How many times do you really believe these two co-workers
> can exchange the same file without the gradients
> exhibiting some significant (recognizable) posterization,
> ...>>
>
> You appear to be confusing me with someone else. ...
I didn't mean to imply you were one of the original advocates. My point and example addressed your "2nd" criteria for proving the use of highbits is better practice than not. That is, your 2nd criteria
addressed the exacerbation of effect if it could be shown a practice
was accumulative. The above example is such a case, whereby two
co-workers constantly exacerbated an effect of constantly changing
gamma in two 8bit color spaces. The resulting histogram knockouts
wouldn't have happened if the 2 co-workers had been using 16bit space.
For sure, an obvious and extreme example of "poor practice", and I
should have been more clear about which point I was addressing.
shAf :o)
------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Wed, Apr 25, 2001, 3:49 PM
RE: RE: [colortheory] "Damage" v. "Data Loss"
Shaf writes,
>>I would agree, generally speaking, a well exposed and normal image does
not require highbit tools. However, I have been confronted with a backlit
and underexposed subject, which offered only 20 shades to play with in 8bit
space. If the desire is to add contrast and brighten this part of the
image, I'd surely end up with posterization. However, if I scan into
highbit space, the number of shades increased to near 100, and now I have
something to work with.>>
I have done experiments like this myself and found that the improvement is
negligible--the files were different, but as a result of the Photoshop
calculation, not the quality of the scan.
IOW, I tried three ways of applying the same drastic series of curves to
the image: once in 16-bit, once in 8-bit, and once in 16-bit that had been
converted to 8-bit and then reconverted to 16-bit. This last gave a result
indistinguishable from the one that had been in 16-bit all along, from
which I concluded that at least in my case, the $50,000 scanner I was using
was just giving random noise in all the extra bits (and probably quite a
lot in the first eight).
Again, if you have a raw scan like this, and can show any kind of real-world advantage with any series of moves however drastic, I'd love to get a hold of it.
Only 20 levels per channel in a dark image won't necessarily cause
posterization--I've printed just such an image in this month's EP, an
underexposed picture of a black cat at night. If posterization happens, it's because the original 8 bits are bad. Adding 8 more bits of random data won't help.
Dan Margulis
------------------
From: "shAf", INTERNET:michael@shaffer.net
To: Dan Margulis, 76270,1033
Date: Wed, Apr 25, 2001, 4:15 PM
RE: RE: [colortheory] "Damage" v. "Data Loss"

Dan writes ...
> Shaf writes,
>
> >>I would agree, generally speaking, a well exposed and
> normal image does not require highbit tools.
> However, I have been confronted with a backlit
> and underexposed subject, which offered only 20 shades to
> play with in 8bit space. ...>>
>
> I have done experiments like this myself and found that
> the improvement is negligible--the files were
> different, but as a result of the Photoshop
> calculation, not the quality of the scan.
> ...
I think we understand eachother's argument ... me, from a "best
practice" point of view which assumes RGB data approachs perfection
(even when it doesn't) ... and you, from a "real world" point of view
who is familiar with scanners which cannot provide RGB which justifies
highbit adjustments.
Regarding and example, I may be able to come up with something ...
but I'm in the middle of selling a home and moving everything across
the north american continent ... my archives are packed, but I'll see
what's on my hard disk.
shAf :o)
------------------From: "Jerry L. P'Simer", INTERNET:jpsimer@twmi.rr.com
Date: Wed, Apr 25, 2001, 8:30 PM
RE: Re: [colortheory] Lab Conversion in 6.0
I am surprised to see that this thread is still going and going,,,.... So at
this time I would Like to add my final two cents
<Stephen Marsh.Writes
As graphics becomes broader and more users use wider gamut working spaces and
output - the
context of a discussion should be firmly established. What applies to
traditional halftone
press printing might not apply to alternate devices.>
I agree. I made an assumption that this group was for the purpose of how to
better approach color needs as they pertain to Lithographic printing. I believe
that Dans writing by and large is for the purpose of addressing these issues
and it is for these purposes that I made the statements that I made.
Andrew Rodney wrote:
We 3damage2 our files all the time (unless we either work on a high bit file
or keep high bit archives in RGB). I1m not suggesting we do, or not do an
RGB to LAB to RGB conversion and then multiple tonal corrections on an 8 bit
file (I would suggest at least using adjustment layers so the multiple tonal
corrections are applied with a single convolution and thus reduces damage to
the file).>
It is also my assumption that if we need to work on an image it is for the
better good of the image. If you consider this damage, again I disagree,
otherwise what is the point?
<We can ignore the issue and pretend that any or all of these kinds of
corrections are lossless (which they are not) or we can be aware of the
possible consequences of such actions, be accurate in what we are doing to
our files and only do such corrections where there is a clear benefit.>
I can assure you that if I am retouching an image for purposes other than
litho, that I take all necessary precautions to preserve the integrity of the
file for later transparency output or other purpose aside from lithographic
needs. But it should also be understood that this image will be repurposed by
me for lithographic reproduction and handled accordingly. What works for one
purpose may not always work for CMYK reproduction which means that further
manipulation may well indeed be required. Including RGB<LAB>RBG>CMYK
conversions when necessary.
Andrew Rodney wrote:
<Trueindeed. But the damage could already be in place for the next user to
compound upon.>
I had stated that what happens to an image after it leaves my possession is
beyond my control. Files that leave my possession do so by way of CFO written
to CD or Final Scitex files shipped as film or transmitted electronically as
well as Tiff-it and by other means.
The point is that they are intended for magazine publishing purposes
(advertising). To my knowledge these images have never been repurposed for any
other reason after leaving my hands. That is not to say that they can not or
have not been repurposed but they are not prepared for this purpose. If one
chooses to do so than they do so at their own risk.
Andrew, I use colormatch RGB on a Mac. If I convert my RGB image to LAB for
correction(for the better good of the file) and then back to RGB for other
purposes before converting to CMYK, I still maintain that this is a virtually
lossless conversion process. If you can indeed look at the final printed image
and state unequivocally the number of times that I have made this conversion or
whether it has been made at all, than I will retract the statements that I have
made and humbly apologize for have made them in the first place.
If you could apply any or all corrections with no data loss, even though you
couldn1t see the difference, would you?
Of course I would. But if indeed the files is being damaged(IF a tree falls in
the forest) and this damage can not be seen by human eyes(with no one to hear)
than is there really damage at all(does it make a sound)? Maybe so. But I say
who cares!!!
Jerry P'Simer-------------------------From: "Dave King", INTERNET:kingphoto@mindspring.com
Date: Thu, May 3, 2001, 12:10 PM
RE: Re: [colortheory] "Damage" v. "Data Loss"
I expected this comment to generate more discussion, and I'm surprised
it didn't. It certainly seems clear in my experience that you run
into posterization much more quickly *starting* with an 8-bit file.
But perhaps you are saying there are 8-bit workarounds that eliminate
this problem? If so, wanna share? :)
When I was starting with digital I was using 24 bit outsourced scans
that were dark and flat. After corrections I couldn't see
posterization on the (uncalibrated at that point) monitor, but it was
clear as a bell in print.
A photographer I know who does high quality large format ink jet
printing has said that taking 24 bit RGB files to 36 bit for complex
tonal edits reduces posterization slightly. His workflow is to
duplicate the original 24 bit file and change it to a 36 bit file,
then use adjustment layers on the 24 bit file, then transfer the
corrections to the duplicate 36 bit file, and last downsample again to
24 bit. This leaves him with a direct comparison, and he claims to
see differences.
There has been a thread on Cone's piezography list recently where Bill
Bergh of Cone Workshop said (among other things):
-----------------------
3 - Because Piezography renders 1% increments well - an image
histogram with the "fingers of death" will print poorly.
5 - Using the Levels or Curve adjustment tools that artificially set
the white and black points often stretch out the midtones and cause a
poor print.
2 - Do levels and curves for tonal changes at the higher bit depth.
When converting to 8-bit greyscale, you will have a smooth histogram.
Levels and curves adjustments in 8-bit can cause the "fingers of
death" as a result of math round off errors.
8 - Artificially setting the black point and white point in Photoshop
will often stretch out and slightly posterize the midtones, and
usually is reflected in a bad looking histogram. This is a leading
trick in all the Photoshop books and is bad advise. It is better to
properly scan the image and let the data fall naturally where it
should. At the scanner you have better control - but it is still not
a great idea to force the endpoints to something that is really not on
the film.
------------------------------
This pertains to Cone's proprietary piezo printing process, where
subtle differences are apparently more pronounced than with other
digital printing processes (I don't use it personally), but in my
experience one doesn't need to go to extremes to run into
posterization problems using 8 bit files.
Dave King
-------------------
From: "Maris V. Lidaka, Sr.", INTERNET:mlidaka@ameritech.net
Date: Thu, May 3, 2001, 2:15 PM
RE: RE: [colortheory] "Damage" v. "Data Loss"

I believe the principle is that each of these 256 values, when tonal or
color adjustments are made, would then result in the new values between the
existing 256 values. Thus when R value 42 is increased it would increase
not to value 43 but to some value between 42 and 43, and this is what
decreases the posterization.
True, little or nothing may be gained, but sometimes it would help.
Maris Lidaka
|------------------
From: "shAf", INTERNET:michael@shaffer.net
Date: Thu, May 3, 2001, 2:06 PM
RE: RE: [colortheory] "Damage" v. "Data Loss"
S
Dave King writes ...
> ...
> A photographer I know who does high quality large
> format ink jet printing has said that taking 24 bit
> RGB files to 36 bit for complex tonal edits reduces
> posterization slightly. His workflow is to duplicate
> the original 24 bit file and change it to a 36 bit
> file, then use adjustment layers on the 24 bit file,
> then transfer the corrections to the duplicate 36 bit
> file, and last downsample again to 24 bit. ...
I have to imagine his observed improvements were subtle.
Realize when you convert 8bits to 16bits you do not create data ...
that is, 0 becomes 0, 1 becomes 255, 2 becomes 511, ..., 255 becomes
65535. You still have 256 values, which means all other 16bit values
have no pixels associated, ... which means any Photoshop "adjustment"
still performs only 256 calculations, and 256 values is all you end up
with, which ultimately are all that is available when you convert back
to 8bit. These 256 values do get moved around in 16bit space more
precisely, but you never create more than 256 values, which are of
course subject to the same round-up problems when you convert back to
8bit. I do believe it is possible to point at circumstances where
these 256 values are less likely to get clipped and lost, and if
several adjustments are done, the final calculation will be more
accurate ... but it would seem very little is gained from converting
8bits to 16 for Photoshop adjustments, and then converting back.
shAf :o)-------------------
From: Dan Margulis, INTERNET:76270.1033@compuserve.com
Date: Thu, May 3, 2001, 4:44 PM
RE: Re: [colortheory] "Damage" v. "Data Loss"
Dave King writes,
>>I expected this comment to generate more discussion, and I'm surprised it
didn't. It certainly seems clear in my experience that you run into
posterization much more quickly *starting* with an 8-bit file. But perhaps
you are saying there are 8-bit workarounds that eliminate this problem? If
so, wanna share? :)>>
The reason the thread died out was that it had become repetitive. Some people said, I feel happier doing it this way, but can't prove that it's better. Others said it's "generally recognized" or "certainly seems clear" and offered to show us a histogram.
My response is, 1) lots of people feel more comfortable adjusting their
images with Brightness/Contrast and believe that other ways aren't any better; 2) "Generally recognized", etc., and $1.50 gets you on the subway; 3) With some rare exceptions, the use of histograms in a discussion about image quality creates a strong inference of lack of understanding of the process.
It's gotta be easier for people taking this position to load some files on
a CD and ship them to me than it is to keep posting the same stuff. Just say what you did to them and what the output conditions were. I don't care how drastic the moves were, and I don't care how challenging the output conditions. If there really is a quality difference between working the files in 16-bit and just converting right away to 8-bit and doing the same things, I would sincerely like to see this. So far I haven't, but I have an open mind on the subject.
People who aren't willing to provide such files should, in my view,
discontinue the discussion.
>>When I was starting with digital I was using 24 bit outsourced scans that
were dark and flat. After corrections I couldn't see posterization on the
(uncalibrated at that point) monitor, but it was clear as a bell in
print.>>
If there is real posterization in the file, it will be visible on the
monitor. If there is posterization in print but not in the file, this is
usually a function of the output device and can ordinarily be defeated by adding noise. Using 16-bit in such a file does the same thing with a lot more effort.
>>A photographer I know who does high quality large format ink jet printing has said that taking 24 bit RGB files to 36 bit for complex tonal edits
reduces posterization slightly. His workflow is to duplicate the original
24 bit file and change it to a 36 bit file, then use adjustment layers on
the 24 bit file, then transfer the corrections to the duplicate 36 bit
file, and last downsample again to 24 bit. This leaves him with a direct
comparison, and he claims to see differences.>>
Of course there are differences. The question is, do the differences make the file better, or worse?
Unless he has a computer-generated gradient or something similar, when he converts a file from 8-bit to 16-bit (I don't know where the 12-bit you're citing comes from), he is simply doubling the size of the file by adding random data. The extra bits mean nothing statistically.
In short, what he is doing is--adding noise. And sometimes, as we all know,
adding noise is a good idea. Other times it isn't. But one thing is for
sure: adding noise by means of the filter is quicker than doing it by
converting and reconverting out of 16-bit.
Dan Margulis
------------------
From: "Dave King", INTERNET:kingphoto@mindspring.com
Date: Fri, May 4, 2001, 10:49 AM
RE: Re: [colortheory] "Damage" v. "Data Loss"

> But one thing is for
> sure: adding noise by means of the filter is quicker than doing it
by
> converting and reconverting out of 16-bit.
That's the tid bit I was looking for. Thanks Dan.
------------------

Adobe Photoshop training classes are taught in the US by Sterling Ledet & Associates, Inc.