How EXACTLY does Gamma relate to the Input/Output values in the Levels dialog box?
If one makes a graduated stepped grayscale, where the input levels are zero for the darkest black, 255 for the lightest white, and plops the middle gray at 127, then adjusts the Levels Gamma to 2.0; the black remains at 0, white at 255, while the middle gray changes to 180. Overall, the shadows develop more contrast, the highlights, less.
If one then plots the resulting input/output values from each of the gray panels of the changed grayscale onto the Curves “graph”, one is left with a shape (and resulting image) that is significantly different from the curve which would be generated by simply moving the middle gray input/output value from 127/127 to 127/180.
Regardless of how I fiddle with the input/output numbers, I cannot find an obvious relationship between those and the value for Gamma. Compounding the problem is that since gamma appears to be a logarithmic function, a gamma = 2 should be 10 times the “relationship” of gamma = 1; gamma = 3, 100 times, etc.
How EXACTLY does Photoshop calculate those input/output values? What internal equation does it use?
On Wed, 02 Sep 1998 11:48:10 -0400, Bill Henry <malt...@earthlink.com> wrote: >How EXACTLY does Photoshop calculate those input/output values? What >internal equation does it use?
Gamma function, in 8-bit system is (as usual assumes that the black-point is set up correctly):
output=INT(255*((input/255)^gamma) +0.5)
The middle input box in Photoshop Levels-dialog has an Adobe tweak (Mr. Cox calls it the "slope limiting"). Due to this tweaking the shadows will be not properly affected by the "gamma" value in the box. So that control can not be used for gamma compensation, the error is very large. Also the number in that dialog is 1/"gamma".
Adobe really should provide an option so that those who need/want to use the proper gamma could do so. Because of this problem I have made (using Excel) a large bunch of *.amp files that you can use in Curves-dialog to apply an accurate gamma (or inverse gamma) , please download from the bottom of the page http://www.clinet.fi/~timothy/calibration/linear.htm
The on-line display compensation in Photoshop 5.0 has another "slope limiting". This is even bigger problem, since the shadows appear differently in Photoshop than in other application. For that too there should be an option.
Well, Timo's math is almost right, for a change. Unfortunately he still has no clue about how gamma really works, what gamma is used/useful for, or If you want a lot of hand waving and mis-information, go ahead and look at his web sites -- they're good for a laugh, just don't try to follow any of his instructions.
Chris
PS. the slope limiting is a good thing, if you understand what's going on, and it normally has a very small effect.
In article <35f9cbb2.11577...@news.clinet.fi>, timo...@clinet.fi (Timo
Autiokari) wrote: > On Wed, 02 Sep 1998 11:48:10 -0400, Bill Henry <malt...@earthlink.com> wrote:
> >How EXACTLY does Photoshop calculate those input/output values? What > >internal equation does it use?
> Gamma function, in 8-bit system is (as usual assumes that the black-point is set > up correctly):
> output=INT(255*((input/255)^gamma) +0.5)
> The middle input box in Photoshop Levels-dialog has an Adobe tweak (Mr. Cox > calls it the "slope limiting"). Due to this tweaking the shadows will be not > properly affected by the "gamma" value in the box. So that control can not be > used for gamma compensation, the error is very large. Also the number in that > dialog is 1/"gamma".
> Adobe really should provide an option so that those who need/want to use the > proper gamma could do so. Because of this problem I have made (using Excel) a > large bunch of *.amp files that you can use in Curves-dialog to apply an > accurate gamma (or inverse gamma) , please download from the bottom of the page > http://www.clinet.fi/~timothy/calibration/linear.htm
> The on-line display compensation in Photoshop 5.0 has another "slope limiting". > This is even bigger problem, since the shadows appear differently in Photoshop > than in other application. For that too there should be an option.
On Sat, 05 Sep 1998 18:31:57 -0700, c...@slip.net (Chris Cox) wrote: >If you want a lot of hand waving and mis-information, go ahead and look at >his web sites -- they're good for a laugh, just don't try to follow any of >his instructions.
Well, most of the people who choose to experiment with linear calibration do not even think switching back since it gives much better control and results.
>PS. the slope limiting is a good thing, if you understand what's going on, >and it normally has a very small effect.
So, why is it there in the first place if it has only a "very small effect" ? And in cases it does have an effect it is only a bad effect, the very same image shows differently in other sw like a viewer than in PS50 and they print differently also. Because viewers and printers do not have the Adobe "slope limiting" tweak.
And why it can not be switched off, there are other photos50.ini settings so adding one for the "slope limiting" would not be too difficult? Not all PS users want to limit their images.
In article <35f380d2.16491...@news.clinet.fi>, timo...@clinet.fi (Timo
Autiokari) wrote: > On Sat, 05 Sep 1998 18:31:57 -0700, c...@slip.net (Chris Cox) wrote: > >If you want a lot of hand waving and mis-information, go ahead and look at > >his web sites -- they're good for a laugh, just don't try to follow any of > >his instructions.
> Well, most of the people who choose to experiment with linear calibration do not > even think switching back since it gives much better control and results.
No, most of the people who follow your 'calibration' instructions end up calling Adobe tech support who walk them through how to undo your instructions and slowly explain all of your mistakes.
> >PS. the slope limiting is a good thing, if you understand what's going on, > >and it normally has a very small effect.
> So, why is it there in the first place if it has only a "very small effect" ? > And in cases it does have an effect it is only a bad effect, the very same image > shows differently in other sw like a viewer than in PS50 and they print > differently also. Because viewers and printers do not have the Adobe "slope > limiting" tweak.
It's there because that small effect is quite noticable to the human eye. Funny, I was just talking to some programmers of other major editing packages last week - and they all use slope limiting.
> And why it can not be switched off, there are other photos50.ini settings so > adding one for the "slope limiting" would not be too difficult? Not all PS > users want to limit their images.
It can't be turned off because there is no good reason to turn it off. So far you're the only one who doesn't want it -- and that's because you haven't got the faintest clue what it is or why it's there and you have the worlds most idiotic 'calibration' on your system.
Chris Cox (c...@slip.net) wrote: > No, most of the people who follow your 'calibration' instructions end up > calling Adobe tech support who walk them through how to undo your > instructions and slowly explain all of your mistakes.
I wonder how it feels to be Chris Cox, knowing that so long as you hold your current position at Adobe, you are going to be writing Usenet responses to Timo, restating your position again and again ... indefinitely.
Also I wonder how it feels to be Timo, knowing that you will be hammering away at the same theme, promoting the same universally debunked ideas, regardless of any and all refutations from highly qualified professionals, day after day, month after month ... indefinitely.
On Sun, 06 Sep 1998 18:32:26 -0700, c...@slip.net (Chris Cox) wrote: >No, most of the people who follow your 'calibration' instructions end up >calling Adobe tech support who walk them through how to undo your >instructions and slowly explain all of your mistakes.
That is not the case. I get mostly success reports, only a few people have said they went back to gamma space and the reason has always been because it is little bit more easy to work with gamma images. But now that the Actions are working well that small problem is only a question of a simple Action.
Mr. Cox said:
>> >PS. the slope limiting is a good thing, if you understand what's going on, >> >and it normally has a very small effect. And then he said: >It's there because that small effect is quite noticable to the human eye.
So, the "slope limiting" has normally a very small effect that is quite noticeable for human eye. Sounds interesting. Everyting that is done in PS is for human eye.
If you e.g compose some dark graphics over your images then the "slope limiting" will be readily noticeable, not while in PS5 but as soon the image is printed or viewed in some other application or put to www.
>Funny, I was just talking to some programmers of other major editing >packages last week - and they all use slope limiting.
Is there other major packages than Photoshop? Only two sw packages for PC that I know applies the slope limiting, all other do on-line viewing accurately.
>It can't be turned off because there is no good reason to turn it off. >So far you're the only one who doesn't want it
Yes, I can believe this. It calls some inspecting to find your the reason why the shadows in some images look bad. Hence, so far most of the people do not know the root cause of the problem in the first place.
It seems that on the other hand Adobe supports the gamma space due to the "better" gradation in the shadows. But on the other hand Adobe damages those same shadows by applying a "slope limiting" there. Odd reasoning.
The "slope limiting" is not good, simply because it is not universal. Printers do not follow it nor does browsers or other sw. Now when you edit images in Photoshop 5.0 then the slope limiting makes the shadows to appear less than they do in other apps or devices. So you can over-do the shadows without noticing it.
>-- and that's because you haven't got the faintest clue what it is or why it's >there
It is there because the RGB to Lab and RGB to CMYK reduces colors by a factor of 6 to 8. So after the conversion the reduced gradation in the shadows becomes visible unless it is "slope limited".
>and you have the worlds most idiotic 'calibration' on your system.
So why on earth does the Photoshop allow such an idiotic calibration? In both Adobe Gamma application and in the RGB setup of PS5?
Timo Autiokari wrote: > That is not the case. I get mostly success reports, only a few people > have said > they went back to gamma space and the reason has always been because > it is > little bit more easy to work with gamma images.
This is simply untrue, if you mean for us to take your use of the word "always" seriously. I tried your system, back before Mssrs. Martindale, Poynton, Cox, etc. ad infinitum had posted here and elsewhere to debunk your method. I followed your instructions very carefully, used unity gamma for a time while preparing for an exhibition, and dropped it when my prints started coming back with (you guessed it, Dave), strange contouring in the shadows (subject matter was physically manipulated Polaroid SX-70 images). And this was before there were any sides to take, or any expert opinion to use as a guide in what artifacts to look for. I e-mailed you at the time informing you of my findings. Working ease had absolutely nothing to do with my return to gamma space; quality tonal rendering did.
> >No, most of the people who follow your 'calibration' instructions end up > >calling Adobe tech support who walk them through how to undo your > >instructions and slowly explain all of your mistakes.
> That is not the case. I get mostly success reports, only a few people have said > they went back to gamma space and the reason has always been because it is > little bit more easy to work with gamma images. But now that the Actions are > working well that small problem is only a question of a simple Action.
Well, it's good to know that you can correspond with the other inmates in the asylum. (because nobody else is gullible enough to keep using your insane 'calibration')
> Mr. Cox said: > >> >PS. the slope limiting is a good thing, if you understand what's going on, > >> >and it normally has a very small effect. > And then he said: > >It's there because that small effect is quite noticable to the human eye.
> So, the "slope limiting" has normally a very small effect that is quite > noticeable for human eye. Sounds interesting. Everyting that is done in PS is > for human eye.
> If you e.g compose some dark graphics over your images then the "slope limiting" > will be readily noticeable, not while in PS5 but as soon the image is printed or > viewed in some other application or put to www.
If it's not noticable in Photoshop, then it won't be noticable elsewhere -- assuming you've calibrated everything correctly and the other programs make use of calibration and ICC profiles. Since you can't even seem to make up your mind what system you're calibrating to (linear, log, gamma 1.25, or whatever you call it this week) I don't doubt that it's going to show problems on YOUR system. For everybody else, it's not a problem.
> >Funny, I was just talking to some programmers of other major editing > >packages last week - and they all use slope limiting.
> Is there other major packages than Photoshop? Only two sw packages for PC that > I know applies the slope limiting, all other do on-line viewing accurately.
Yes, there are other major packages (well, in the consusmer and enterprise markets :-), and some of their programmers were at Seybold (and I even had time to speak to them between meetings - wow!).
> >It can't be turned off because there is no good reason to turn it off. > >So far you're the only one who doesn't want it
> Yes, I can believe this. It calls some inspecting to find your the reason why > the shadows in some images look bad. Hence, so far most of the people do not > know the root cause of the problem in the first place.
No, for everyone else the shadows look good. Only your shadows look bad - and that's because of your 'calibration', not because of slope limiting in gamma calculations.
> It seems that on the other hand Adobe supports the gamma space due to the > "better" gradation in the shadows. But on the other hand Adobe damages those > same shadows by applying a "slope limiting" there. Odd reasoning.
No, both are improving the quality. The only damage appears to be to the rear surface of your own cerebrum.
> The "slope limiting" is not good, simply because it is not universal. Printers > do not follow it nor does browsers or other sw. Now when you edit images in > Photoshop 5.0 then the slope limiting makes the shadows to appear less than they > do in other apps or devices. So you can over-do the shadows without
noticing it.
Printers don't follow gamma at all - they have dot gain, which is a MUCH more complex topic. Yes, editing in Photoshop 5 can give a different appearance than in other programs -- at least until the other programs catch up on their calibration and use of ICC profiles.
> >-- and that's because you haven't got the faintest clue what it is or why it's > >there
> It is there because the RGB to Lab and RGB to CMYK reduces colors by a factor of > 6 to 8. So after the conversion the reduced gradation in the shadows becomes > visible unless it is "slope limited".
Does your analyst know that you're back into conspiracy theories?
> >and you have the worlds most idiotic 'calibration' on your system.
> So why on earth does the Photoshop allow such an idiotic calibration? In both > Adobe Gamma application and in the RGB setup of PS5?
Because there are a few cases where such things are needed and can be useful to people who understand gamma, color and human vision. And no matter how 'idiot proof' we make the tools, the universe is always creating bigger and better idiots.
> Yes, there are other major packages (well, in the consusmer and enterprise > markets :-), and some of their programmers were at Seybold (and I even had > time to speak to them between meetings - wow!).
Bet you guys had a good laugh when the T-subject came up... or maybe you just talked about interesting things...;-)
On Mon, 07 Sep 1998 16:47:49 -0700, c...@slip.net (Chris Cox) wrote: >If it's not noticable in Photoshop, then it won't be noticable elsewhere -- >assuming you've calibrated everything correctly and the other programs make >use of calibration and ICC profiles.
And assuming that all the other sw and devices embed the "slope limiting" also, but they do not.
>> The "slope limiting" is not good, simply because it is not universal. Printers >> do not follow it nor does browsers or other sw. >Printers don't follow gamma at all - they have dot gain, which is a MUCH >more complex topic.
Correct, printers do not follow gamma at all, natively, but most printers have been set into a gamma space (usually 1.8). The point is that they do not follow the slope limiting. Unless there is an inverse-slope-limiting buried into the profile that Photoshop embeds into the image then the slope limiting does nothing but degradations.
>Yes, editing in Photoshop 5 can give a different appearance than in other >programs -- at least until the other programs catch up on their calibration >and use of ICC profiles.
So this means that there _is_ an inverse-slope-limiting buried into the profile?
>> It is there because the RGB to Lab and RGB to CMYK reduces colors by a >factor of 6 to 8. So after the conversion the reduced gradation in the shadows >>becomes visible unless it is "slope limited".
>Does your analyst know that you're back into conspiracy theories?
Are you now saying that the eye is not sensitive in the shadows so that the image quality stays intact after the 6 to 8 fold color reduction?
>> So why on earth does the Photoshop allow such an idiotic calibration? In both >> Adobe Gamma application and in the RGB setup of PS5?
>Because there are a few cases where such things are needed and can be >useful to people who understand gamma, color and human vision. And no >matter how 'idiot proof' we make the tools, the universe is always creating >bigger and better idiots.
From that I assume that the gamma spaces in turn are useful for people who do not understand gamma, color and human vision.
So idiotic calibration is needed in a few cases. A few cases indeed, like color/tonal/hue accuracy and error free editing.
On Mon, 07 Sep 1998 14:00:02 -0400, Valburg <l...@psu.edu> wrote: >Timo Autiokari wrote: >> That is not the case. I get mostly success reports, only a few people >> have said they went back to gamma space and the reason has always >>been because it is little bit more easy to work with gamma images. >This is simply untrue, [...]I e-mailed you at the time informing you of my findings. >Working ease had absolutely nothing to do with my return to gamma space; quality >tonal rendering did. >Regards, >Mitch Valburg
I went through my mail backups and I have got 4 e-mails from you, I couldn't find you saying anything about: "Working ease had absolutely nothing to do with my return to gamma space; quality tonal rendering did." At that time you were struggling to get the PS4 and your scanner into (any) calibration.
The feedback that I have got has been very positive. I can not find any message with a complaint about the shading in deep shadows.
Only a few people have said that they went back to gamma space. There has been two reasons actually: one is the easy operation and the other is that Windows default color scheme (the way Windows shows window borders, buttons etc) looks awful when the system is gamma 1.0 calibrated.
Now, with PS 5.0 there is no (big) need to set the system itself into gamma space, one can work with linear images simply by setting the RGB gamma to 1.0.
If one wants to have the system also in gamma 1.0 (using Adobe Gamma in case PS5, or using display driver control with PS4) then changing the "3D Objects" in the Display Properties -dialog to a darker gray will bring the Windows colors back in order.
> >If it's not noticable in Photoshop, then it won't be noticable elsewhere -- > >assuming you've calibrated everything correctly and the other programs make > >use of calibration and ICC profiles.
> And assuming that all the other sw and devices embed the "slope limiting" also, > but they do not.
That statement makes even less sense than your normal drivel.
> >> The "slope limiting" is not good, simply because it is not universal. Printers > >> do not follow it nor does browsers or other sw.
> >Printers don't follow gamma at all - they have dot gain, which is a MUCH > >more complex topic.
> Correct, printers do not follow gamma at all, natively, but most printers have > been set into a gamma space (usually 1.8).
That's only true if they're working with RGB data. If the printer is working with CMYK (or other inks) data, then gamma doesn't make much sense.
> The point is that they do not follow the slope limiting. > Unless there is an inverse-slope-limiting buried into the > profile that Photoshop embeds into the image then the slope limiting does > nothing but degradations.
> >Yes, editing in Photoshop 5 can give a different appearance than in other > >programs -- at least until the other programs catch up on their calibration > >and use of ICC profiles.
> So this means that there _is_ an inverse-slope-limiting buried into the
profile?
Once again, your ignorance is showing. Inversion is inherent in the profile and one of the big reasons to USE slope limiting.
Today's thought experiment that Timo will ignore once again: what happens when you invert a zero or near zero slope?
> >> It is there because the RGB to Lab and RGB to CMYK reduces colors by a > >factor of 6 to 8. So after the conversion the reduced gradation in the shadows > >>becomes visible unless it is "slope limited".
> >Does your analyst know that you're back into conspiracy theories?
> Are you now saying that the eye is not sensitive in the shadows so that the > image quality stays intact after the 6 to 8 fold color reduction?
No, I said what I said - while what you said is paranoid cojecture following bad math and conclusions reached through ignorance instead of investigation despite being handed all the references and math that would lead you to more correct conclusions.
> >> So why on earth does the Photoshop allow such an idiotic calibration? In both > >> Adobe Gamma application and in the RGB setup of PS5?
> >Because there are a few cases where such things are needed and can be > >useful to people who understand gamma, color and human vision. And no > >matter how 'idiot proof' we make the tools, the universe is always creating > >bigger and better idiots.
> From that I assume that the gamma spaces in turn are useful for people who do > not understand gamma, color and human vision.
No, a few cases like when I'm editing raw photon counts from a particle physics experiment and want a better feel for the distribution. Or when calibrating ultra low light astronomical sensors. In these cases you have linear light values and don't need to worry about color accuracy - because there is no color.
> So idiotic calibration is needed in a few cases. A few cases indeed, like > color/tonal/hue accuracy and error free editing.
For cases where people want good color, tonal reproduction and hue accuracy: they are (and rightfully should be) using a gamma between 1.8 and 2.5. If they want lousy color reproduction, severe banding in the shadows, poor hue accuracy, and to make themselves look like fools in an international forum: then they can try to edit images in gamma 1.0 space.
> >Timo Autiokari wrote: > >> That is not the case. I get mostly success reports, only a few people > >> have said they went back to gamma space and the reason has always > >>been because it is little bit more easy to work with gamma images.
> >This is simply untrue, [...]I e-mailed you at the time informing you of my findings. > >Working ease had absolutely nothing to do with my return to gamma space; quality > >tonal rendering did. > >Regards, > >Mitch Valburg
> I went through my mail backups and I have got 4 e-mails from you, I couldn't > find you saying anything about: "Working ease had absolutely nothing to do with > my return to gamma space; quality tonal rendering did." At that time you were > struggling to get the PS4 and your scanner into (any) calibration.
> The feedback that I have got has been very positive.
The only way you could have gotten 'positive' feedback on this crock of yours would be through electro-convulsive shock therapy.
> I can not find any message > with a complaint about the shading in deep shadows.
Oh, no, Timo's gone into selective recall and reading. Tell the doctor to up the amperage.
> Only a few people have said that they went back to gamma space. There has been > two reasons actually: one is the easy operation and the other is that Windows > default color scheme (the way Windows shows window borders, buttons etc) looks > awful when the system is gamma 1.0 calibrated.
> Now, with PS 5.0 there is no (big) need to set the system itself into gamma > space, one can work with linear images simply by setting the RGB gamma to 1.0.
Yeah, but most people know better. If not, they do a few simple experiments and find out just how wrong you are.
c...@slip.net (Chris Cox) writes: >For cases where people want good color, tonal reproduction and hue >accuracy: they are (and rightfully should be) using a gamma between 1.8 and >2.5. >If they want lousy color reproduction, severe banding in the shadows, poor >hue accuracy, and to make themselves look like fools in an international >forum: then they can try to edit images in gamma 1.0 space.
To be fair, all this applies to 8-bit samples only.
If you can afford 10 bits per sample, the Cineon log encoding is better in a number of ways than 8-bit linear or 8-bit gamma encoded. (For storage; logarithmic codes sometimes need to be converted to wider linear codes for some calculations)
And if you use 16 (integer) bits per sample or use floating point storage of intensity, operating in linear space works very well indeed.
It's just that 8 bits per sample is too few to work well with a linear code, unless the image intensity range is quite small.
c...@slip.net (Chris Cox) wrote: >If they want lousy color reproduction, severe banding in the shadows, poor >hue accuracy, and to make themselves look like fools in an international >forum: then they can try to edit images in gamma 1.0 space.
HEADLINE Finland:
The fiords are being tinted with a reddish liquid (it appears to be human blood) after the last two USENET posts reached here. Evidently, gaping neck wounds were found in a local guy's throat. The words "REDRUM" and "0.1 AMMAG" were found drawn in blood on the victim's room, near the computer.
GIF at 11 ;)
----------------------------------------- VIRTUE...is its own punishment. http://diversify.com/ljaques/ Graphic Design for Print & the Web =============================================================
> If you can afford 10 bits per sample, the Cineon log encoding is better > in a number of ways than 8-bit linear or 8-bit gamma encoded. (For storage; > logarithmic codes sometimes need to be converted to wider linear codes > for some calculations)
Dave-
Why wouldn't the perceptually-based encoding be superior at 10 bits as much as 8 bits?
In article <6t69tt$8g...@columbia.cs.ubc.ca>, da...@cs.ubc.ca (Dave
Martindale) wrote: > c...@slip.net (Chris Cox) writes: > >For cases where people want good color, tonal reproduction and hue > >accuracy: they are (and rightfully should be) using a gamma between 1.8 and > >2.5. > >If they want lousy color reproduction, severe banding in the shadows, poor > >hue accuracy, and to make themselves look like fools in an international > >forum: then they can try to edit images in gamma 1.0 space.
> To be fair, all this applies to 8-bit samples only.
> If you can afford 10 bits per sample, the Cineon log encoding is better > in a number of ways than 8-bit linear or 8-bit gamma encoded. (For storage; > logarithmic codes sometimes need to be converted to wider linear codes > for some calculations)
I still haven't seen great quality out of Cineon samples. (admittedly, I haven't had the time to do that many tests with them)
And despite the fact that I could use linear 16 bit data, I prefer to use all of those 16 bits and keep it gamma encoded.
On Tue, 08 Sep 1998 21:03:59 -0700, c...@slip.net (Chris Cox) wrote: >> Correct, printers do not follow gamma at all, natively, but most printers have >> been set into a gamma space (usually 1.8).
>That's only true if they're working with RGB data. If the printer is working with >CMYK (or other inks) data, then gamma doesn't make much sense.
Many of your customers do print in RGB. But it does exactly the same sense in CMYK also, there is the same gamma tweak in CMYK.
>> So this means that there _is_ an inverse-slope-limiting buried into the >profile?
>Once again, your ignorance is showing. Inversion is inherent in the >profile and one of the big reasons to USE slope limiting.
The slope limiting could be in the profile conversions _only_, that would be good.
Now as it is, that the PS5 shows the slope limited data (image) but, presumably, the conversion go by-the-book is not good since the viewing appearance of the image is mangled.
>Today's thought experiment that Timo will ignore once again: what happens >when you invert a zero or near zero slope?
The zero will not be "inverted" by the profile conversions, it stays intact. The next level is level 1 that does not have near zero slope. Even if the profile conversion is done in the 16-bit mode the level 1 there has not a near zero slope either. So, if the slope limiting would be _only_ in the profile conversions then you would get the first levels through the conversion and there would not be a reason to tweak the on-line appearance of the image.
>> Are you now saying that the eye is not sensitive in the shadows so that the >> image quality stays intact after the 6 to 8 fold color reduction?
>No, I said what I said - while what you said is paranoid cojecture >following bad math and conclusions reached through ignorance instead of >investigation despite being handed all the references and math that would >lead you to more correct conclusions.
Anyone can repeat the color reduction experiments and get the same results.
So, you also could possibly do some inspections, since most of the problems are due to the Lab engine that has so centric role in PS. The Lab simply is too steep and it is too wide also, it causes problems even if implemented in 16-bit.
>> So idiotic calibration is needed in a few cases. A few cases indeed, like >> color/tonal/hue accuracy and error free editing.
>For cases where people want good color, tonal reproduction and hue >accuracy: they are (and rightfully should be) using a gamma between 1.8 and >2.5.
So, and people should believe this only because it is written by Adobe code writer? Why does the User Manual not say nor does any www page of Adobe say that linear calibration is bad? You may have noticed that even the gamma party here on the usenet acknowledges the problems that gamma does to colors when images are edited.
>If they want lousy color reproduction, severe banding in the shadows, poor >hue accuracy, and to make themselves look like fools in an international >forum: then they can try to edit images in gamma 1.0 space.
I do not mind if someone is seeing myself as a fool on any forum due to calibration issues, I only mind about the image quality. Digital photographic imaging is quite large part of my work, I care about my work so that I try to do my best in it.
Timo Autiokari wrote: > I do not mind if someone is seeing myself as a fool on any forum due > to calibration issues, I only mind about the image quality. Digital > photographic imaging is quite large part of my work, I care about > my work so that I try to do my best in it.
As it happens, I don't agree with your conclusions on image calibration -- but it's obvious that you've put a lot of time and work into them. I'm kinda glad you keep posting your side of the issue; I think the resulting discussion/rehash/holy war is a useful educational tool for the constant influx of new readers.
(I'd also like to throw out general kudos to the group -- for keeping this discussion polite, mostly. The signal-to-noise ratio is a lot better here than in many other places...)
> >> Correct, printers do not follow gamma at all, natively, but most printers have > >> been set into a gamma space (usually 1.8).
> >That's only true if they're working with RGB data. If the printer is working with > >CMYK (or other inks) data, then gamma doesn't make much sense.
> Many of your customers do print in RGB. But it does exactly the same sense in > CMYK also, there is the same gamma tweak in CMYK.
One more time - there is no gamma in CMYK, just dot gain.
> >> So this means that there _is_ an inverse-slope-limiting buried into the > >profile?
> >Once again, your ignorance is showing. Inversion is inherent in the > >profile and one of the big reasons to USE slope limiting.
> The slope limiting could be in the profile conversions _only_, that would be > good.
> Now as it is, that the PS5 shows the slope limited data (image) but, presumably, > the conversion go by-the-book is not good since the viewing appearance of the > image is mangled.
The appearance is not mangled (except in your mutant eyes).
> >Today's thought experiment that Timo will ignore once again: what happens > >when you invert a zero or near zero slope?
> The zero will not be "inverted" by the profile conversions, it stays intact. The > next level is level 1 that does not have near zero slope. Even if the profile > conversion is done in the 16-bit mode the level 1 there has not a near zero > slope either. So, if the slope limiting would be _only_ in the profile > conversions then you would get the first levels through the conversion and there > would not be a reason to tweak the on-line appearance of the image.
At least you didn't ingore the idea this time, even if you got it 100% wrong.
If the zero slope stays intact during inversion, you get the wrong results - that's obvious (to everyone except yourself). A zero slope in the input must map to an infinite slope in the inverse. But that leads to a few computational problems. The slope is between levels (0 to 1, 1 to 2, etc.) not defined at each level. So if the value at level 0 is the same as the value at level 1, you have a zero slope, and a problem.
And you're still rambling nonsenically, so I can't figure out the rest of what you're talking about.
> >> Are you now saying that the eye is not sensitive in the shadows so that the > >> image quality stays intact after the 6 to 8 fold color reduction?
> >No, I said what I said - while what you said is paranoid cojecture > >following bad math and conclusions reached through ignorance instead of > >investigation despite being handed all the references and math that would > >lead you to more correct conclusions.
> Anyone can repeat the color reduction experiments and get the same results.
They have repeated it: they get different results AND so far most of them (I've only had 2 people ask about the size of the Lab gamut compared to the RGB gamuts) have understood the results they got, unlike yourself. I guess a few of them bothered to read up on it. And none of these people come anywhere near a conclusion that slope limiting is there to hide other bugs that don't exist. Only you reached that conclusion.
> So, you also could possibly do some inspections, since most of the problems are > due to the Lab engine that has so centric role in PS. The Lab simply is too > steep and it is too wide also, it causes problems even if implemented in
16-bit.
Once again you're rambling (or proving that you have even less of an idea of what you're talking about than we've previously suspected).
> >> So idiotic calibration is needed in a few cases. A few cases indeed, like > >> color/tonal/hue accuracy and error free editing.
> >For cases where people want good color, tonal reproduction and hue > >accuracy: they are (and rightfully should be) using a gamma between 1.8 and > >2.5.
> So, and people should believe this only because it is written by Adobe code > writer?
No, most people believe this because it was written by a lot of experts that they trust, or because they have looked into the concept of gamma and discovered that it's right.
> Why does the User Manual not say nor does any www page of Adobe say that > linear calibration is bad?
Does your car manual have to say that driving over a cliff at 200 KPH is bad? Does your body come with a book that says that inhaling natural gas, holding live uninsulated powerlines, putting a stick through your eye, or swimming in boiling oil are bad things to do? No. Some things are just too obvious to spell out. (ok, maybe we should spell it out for the crackheads)
> You may have noticed that even the gamma party here > on the usenet acknowledges the problems that gamma does to colors when images > are edited.
No, they acknowledge that _some_ image processing tasks should be done in a linear light space for best quality. Which is not what you just said. Learn to read.
> >If they want lousy color reproduction, severe banding in the shadows, poor > >hue accuracy, and to make themselves look like fools in an international > >forum: then they can try to edit images in gamma 1.0 space.
> I do not mind if someone is seeing myself as a fool on any forum due to > calibration issues, I only mind about the image quality. Digital photographic > imaging is quite large part of my work, I care about my work so that I try to do > my best in it.
If you cared about your work, and about quality, you would bother to read some of the references we keep sending you to instead of just dismissing them out of hand or rejecting anything they say that doesn't agree with your preconceived notions. You just MIGHT find out that you've been wrong all along. But I guess that's too much to hope for.
On Tue, 08 Sep 1998 21:08:04 -0700, c...@slip.net (Chris Cox) wrote: >> Now, with PS 5.0 there is no (big) need to set the system itself into gamma >> space, one can work with linear images simply by setting the RGB gamma to 1.0.
>Yeah, but most people know better. >If not, they do a few simple experiments and find out just how wrong you are.
And you care not to tell me (and the people here on usenet) what are these simple experiments? Please explain them.
On Thu, 10 Sep 1998 21:28:35 -0700, c...@slip.net (Chris Cox) wrote: >> Many of your customers do print in RGB. But it does exactly the same sense in >> CMYK also, there is the same gamma tweak in CMYK.
>One more time - there is no gamma in CMYK, just dot gain.
Some/most printers do have gamma tweaking in CMYK also. In Photoshop Gamma setting does not affect to display appearance of CMYK-composite view (does affect if you view individual layers).
>The appearance is not mangled (except in your mutant eyes).
It *is* mangled by the slope-liminting and it will hit you every now and then. It would be better to mangle only the profile conversions so that the deep shadow levels goes through.
>At least you didn't ingore the idea this time, even if you got it 100% wrong. >If the zero slope stays intact during inversion, you get the wrong results >- that's obvious (to everyone except yourself). A zero slope in the input >must map to an infinite slope in the inverse. But that leads to a few >computational problems. >The slope is between levels (0 to 1, 1 to 2, etc.) not defined at each >level.
No, gamma conversions are defined for each level. The "slope" is just an expression.
Level 0 does not change what ever gamma or inverse gamma you apply, nor does the level 255 change.
All the other levels will change according to the gamma value by the gamma function, except of course in Photoshop 5.0 that has the "slope limiting".
>And none of these people come anywhere near a conclusion that slope >limiting is there to hide other bugs that don't exist. Only you reached >that conclusion.
Not only me and not only a few other people. Color reduction by a factor of 6 to 8 does show up as banding, unless you use extremely high gamma space.
>> You may have noticed that even the gamma party here on the usenet >>acknowledges the problems that gamma does to colors when images >> are edited.
>No, they acknowledge that _some_ image processing tasks should be done in a >linear light space for best quality. Which is not what you just said. Learn to read.
One will get gamma errors from most of the operations and filters in case one use a high gamma space.
>If you cared about your work, and about quality, you would bother to read >some of the references we keep sending you
You have a strange habit of using the word "we" in a rather peculiar way. Who actually is "we" at this time? I have not received anything that seems to be from "you".
>You just MIGHT find out that you've been wrong all along. >But I guess that's too much to hope for.
It is not a question of hope, show some facts. I want, only, the best accuracy and best quality for my images. I have done a lot of work for the accurate calibration and so far I have found the two benefits of gamma space.
- a bit easier operation (but with heavy drawbacks). - a mathematical benefit in shading at deep shadows.
On the other hands there is a large bunch of important benefits in linear calibration.
I wrote: >> If you can afford 10 bits per sample, the Cineon log encoding is better >> in a number of ways than 8-bit linear or 8-bit gamma encoded. (For storage; >> logarithmic codes sometimes need to be converted to wider linear codes >> for some calculations) Charley Cowens wrote: >Why wouldn't the perceptually-based encoding be superior at 10 bits as much as >8 bits?
The nice thing about 10-bit logarithmic coding is that it can capture a really large intensity range (about 10 f/stops, 1000:1 intensity ratio) with the same relative intensity step size throughout the entire range. You can't display that much intensity range, so you are eventually going to have to select part of the range for display. But you can postpone decisions on that until the very end of the process if you want. All of your image processing operations can be done on the full dynamic range of the image, without deciding in advance what part of the intensity range is "important".
In the movie special effects world, you can scan negatives into the Cineon code, do all of your blue-screen and compositing and touchup in this 10-bit log domain, and write the processed images *back to film* with their 10-stop intensity range intact. The final decisions about brightness/darkness and colour balance of the image are still made during printing of the new negative onto print film, just like is done with the scenes that have not been processed.
In comparison, a perceptually-related coding like "gamma encoding" depends on some assumptions about how the image is eventually going to be viewed. Gamma encoding does a good job of assigning bits to intensity levels if, in fact, the maximum code value is assigned to the maximum *viewed* intensity. But doing this well requires picking that intensity at the time the image is scanned.
For example, suppose some film has been shot under really poor lighting conditions, and the resulting negative is very thin. When scanned with the Cineon system scanner, only the lower code values would be used at all. But to make the scene brighter overall, all you need to do is add a constant to every sample value. It still won't look great, but since the scanner captured essentially all the information that was on the negative in the first place, it's the best you can do with this negative - there's no point in rescanning it.
If you had scanned the same negative into gamma encoded form, the encoding would assign more of the available sample codes to the highlight areas than a log code, and less to the shadows - achieving a balance that is appropriate based on human perception. But for this negative, there *aren't* any bright areas, so all those code values go to waste, and the image is all down in the (fewer) lower- valued codes. When you increase the overall brightness of the scene by multiplying each sample code, you make the scene brighter, but the available intensity steps also get farther apart - so you get poorer intensity resolution than the log code would have given you.
(A note: intensity scaling is done in linear and gamma encoded images by multiplying, but the same effect is done in log encoded images by adding a constant).
In the opposite direction, it's even worse. Assume you have a negative that is too dense because it's overexposed. The log code would just have sample values that are larger than usual - subtract a constant and you have a good-looking image, unless the negative was grossly overexposed. But with gamma encoding, everything brighter than some nominal "white point" has been lost completely. You have no "headroom" above white, so you can't divide the pixel values by a constant to get back the highlight information. You have to change the settings on your scanner and rescan.
In short: log encoding provides a large dynamic range with constant resolution throughout the range, so you can scan, process, and record images without worrying about where the maximum scene white is, or what to do with highlights that go above that (like reflections off chrome objects). Gamma encoding is perceptually better, but only if you actually get perception involved in the process - which means setting the scanner individually for each scene.
By the way, linear encoding is even *more* unlike log encoding than gamma encoding is. It's even more critical to get the white point set correctly during scanning with linear data, because you have even *less* data for the darkest areas. I wouldn't recommend 10 bit linear encoding at all for critical applications.
12-bit linear is adequate for the same things you'd use 8- or 10-bit gamma encoding for, images where the scanner settings are adjusted on a per-scene basis. And 12-bit linear is easier to process, particularly with specialized hardware.
But you have to use 16-bit linear to get, at the same time, the wide intensity range and fine gradations in the darkest areas that you get with only 10 bits of logarithmic code.
Internally, a lot of my software uses 32-bit floating point. It has the advantages of 16-bit linear taken even further, plus there is no need to worry about overflow or underflow in any practical image processing problems. In addition, you don't need to worry about the buildup of roundoff errors at each stage in a complicated series of processing steps. But I hardly ever use this for *storing* images, just *processing* them. (It doesn't hurt that 32-bit FP arithmetic is *faster* than 16-bit integer arithmetic on many CPUs).
Unfortunately all the decent books I know of are written for scientific types. And the books that cover color in 'professional' manner were written before digital imaging was commonplace.
Charles Poynton's book on digital video is supposed to be good -- but I haven't had time to read it yet to see what level of reader it's indended for.
Oh, and, of course, there are no books that agree with Timo's views.
> > >> Now, with PS 5.0 there is no (big) need to set the system itself into gamma > > >> space, one can work with linear images simply by setting the RGB gamma to 1.0.
> > >Yeah, but most people know better. > > >If not, they do a few simple experiments and find out just how wrong you are.
> > And you care not to tell me (and the people here on usenet) what are these > > simple experiments? Please explain them.
> > Timo Autiokari
> This entire thread has been/is lots of fun. Is there a good book on the > subject, explaining the concepts involved, and helping to establish a > starting point for all this. Many of the posts here seem to be from > people who have been on the output side of the industry for years and > are very informed as to the type of file needed to produce results.
> On the image creator side, many of us have not spent alot of time > learning what is involved beyond capturing the right image and dreaming > of seeing it finished (published, whatever) in an acurate representation > of our vision. We have at times been disapointed. The reasons for "our" > understanding are multifold - EGO: It allows us "completion" of an image > as we see/intend it to be presented. COST: If we can reduce time > invested by the output people and still achieve our goal of image > quality we save some money. CONTROL: There are those of us (I hope not > entirely me) that demand to have it, whether it makes for a better > output result or not. (You may note that EGO is not a bad thing. We all > have it. It is how we work with it that makes it pleasant or OTHERWISE.)
> Enough lecture. Sorry. Back to "the book". Something that does not > require one to change profession and lifestyle to understand, but will > help one to work withing the entire cycle of image reproduction to > "complete" thier vision.
|
