If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#221
|
|||
|
|||
Chris Cox wrote:
In article , Mike Russell wrote: Mike Engles wrote: ... [re linear encoding of specialized pixel data values] Is the same true for imaging from spacecraft, interplanetary or otherwise or is gamma encoding done before transmission? Yes. Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. Here's an article that may interest you, by Alvy Ray Smith, on the distinction of work and display color spaces. http://alvyray.com/Memos/MemosMicros...rAlphaQuestion Actually, Alvy has a number of mistakes in that paper. I'm still not sure if he understands gamma encoding... Chris Hello Yes there does seem to some confusion about PC Gamma, but he is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He is totally clear about not applying any non linearity to a image, just to the display device. I assume from this he means the same for storage, but I don't know. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. Mike Engles |
#222
|
|||
|
|||
Mike Engles wrote:
[re alvy gamma article] Hello Yes there does seem to some confusion about PC Gamma, but he [Alvy] is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He is totally clear about not applying any non linearity to a image, just to the display device. I assume from this he means the same for storage, but I don't know. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. Mike Engles Right on. Alvy has another article, written in 1995, that goes into further detail re gamma issues: http://www.cs.princeton.edu/courses/...s/smith95d.pdf .. In this 1995 article, Alvy states: "Nonlinearity should never be stored in an image. Or, if it is, then this nonlinearity must be noted in the storage format in such a way that it is known how to remove it to retrieve linear data." This comment, as fundamental as it is to graphics algorithms, plus others relating to the concept of working versus display space, came years before Photoshop 5 commercially introduced the concept of working spaces, as part of color management. Not bad for someone who "doesn't understand gamma". As for Timo's lonely stance - he appears to be in good company now, having been debunked together with Alvy Ray Smith and Dan Margulis, all in the space of a few days. :-) -- Mike Russell www.curvemeister.com www.geigy.2y.net |
#223
|
|||
|
|||
Mike Russell wrote:
Mike Engles wrote: [re alvy gamma article] Hello Yes there does seem to some confusion about PC Gamma, but he [Alvy] is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He is totally clear about not applying any non linearity to a image, just to the display device. I assume from this he means the same for storage, but I don't know. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. Mike Engles Right on. Alvy has another article, written in 1995, that goes into further detail re gamma issues: http://www.cs.princeton.edu/courses/...s/smith95d.pdf . In this 1995 article, Alvy states: "Nonlinearity should never be stored in an image. Or, if it is, then this nonlinearity must be noted in the storage format in such a way that it is known how to remove it to retrieve linear data." This comment, as fundamental as it is to graphics algorithms, plus others relating to the concept of working versus display space, came years before Photoshop 5 commercially introduced the concept of working spaces, as part of color management. Not bad for someone who "doesn't understand gamma". As for Timo's lonely stance - he appears to be in good company now, having been debunked together with Alvy Ray Smith and Dan Margulis, all in the space of a few days. :-) -- Mike Russell www.curvemeister.com www.geigy.2y.net Hello This curiuosly was the article I was referring to. I was not sure of the legality of quoting from it. Since you have I will also. These are the last words. "Gamma can be confusing, as the above probably illustrates. Here are the simple rules Altamira Composer uses and what I am advocating that imaging applications do as a matter of course: Images are always assumed to be linear. Gamma is applied only to the display of images and not to the data of the images.The display is assumed to be nonlinear (because it is). Applications separate computation from display cleanly, and gamma correct for the local display only in the display process. To get compatible results between imaging applications written under the (I trust you believe sensible) “new” guidelines offered here and those written the “old” way: Set the monitor gamma assumption in all the “old” imaging applications to the same (greater than 1) value—presumably to that matching one’s usual display monitor. Most applications provide a way to do this. This transfers the nonlinearity correction in those apps from the computation process to the display process, as it should be, leaving linear data in the images themselves. A desirable consequence of all this is that it would be very convenient for imaging software if display devices provided gamma correction tables settable by software. That way, each imaging app could work completely in linear space,knowing that the display step would be correctly compensated by the local monitor for its local nonlinearities. Believe it or not, this was the way it was done 20 years ago, but the idea got lost along the way, leading to the mess described in this memo. Unfortunately, it is probably too late to change. The technique offered here is the best that can be done short of changing all the hardware." It seems that there was a differnt way and the only people who use it now are the scientists. I honestly do not know which is right and do not know enough to be able to know, but feel in my bones that the old way was right. Mike Engles |
#224
|
|||
|
|||
Mike Russell wrote:
Mike Engles wrote: [re alvy gamma article] Hello Yes there does seem to some confusion about PC Gamma, but he [Alvy] is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He is totally clear about not applying any non linearity to a image, just to the display device. I assume from this he means the same for storage, but I don't know. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. Mike Engles Right on. Alvy has another article, written in 1995, that goes into further detail re gamma issues: http://www.cs.princeton.edu/courses/...s/smith95d.pdf . In this 1995 article, Alvy states: "Nonlinearity should never be stored in an image. Or, if it is, then this nonlinearity must be noted in the storage format in such a way that it is known how to remove it to retrieve linear data." This comment, as fundamental as it is to graphics algorithms, plus others relating to the concept of working versus display space, came years before Photoshop 5 commercially introduced the concept of working spaces, as part of color management. Not bad for someone who "doesn't understand gamma". As for Timo's lonely stance - he appears to be in good company now, having been debunked together with Alvy Ray Smith and Dan Margulis, all in the space of a few days. :-) -- Mike Russell www.curvemeister.com www.geigy.2y.net Hello This curiuosly was the article I was referring to. I was not sure of the legality of quoting from it. Since you have I will also. These are the last words. "Gamma can be confusing, as the above probably illustrates. Here are the simple rules Altamira Composer uses and what I am advocating that imaging applications do as a matter of course: Images are always assumed to be linear. Gamma is applied only to the display of images and not to the data of the images.The display is assumed to be nonlinear (because it is). Applications separate computation from display cleanly, and gamma correct for the local display only in the display process. To get compatible results between imaging applications written under the (I trust you believe sensible) “new” guidelines offered here and those written the “old” way: Set the monitor gamma assumption in all the “old” imaging applications to the same (greater than 1) value—presumably to that matching one’s usual display monitor. Most applications provide a way to do this. This transfers the nonlinearity correction in those apps from the computation process to the display process, as it should be, leaving linear data in the images themselves. A desirable consequence of all this is that it would be very convenient for imaging software if display devices provided gamma correction tables settable by software. That way, each imaging app could work completely in linear space,knowing that the display step would be correctly compensated by the local monitor for its local nonlinearities. Believe it or not, this was the way it was done 20 years ago, but the idea got lost along the way, leading to the mess described in this memo. Unfortunately, it is probably too late to change. The technique offered here is the best that can be done short of changing all the hardware." It seems that there was a differnt way and the only people who use it now are the scientists. I honestly do not know which is right and do not know enough to be able to know, but feel in my bones that the old way was right. Mike Engles |
#225
|
|||
|
|||
Mike Engles writes:
Actually, Alvy has a number of mistakes in that paper. I'm still not sure if he understands gamma encoding... Yes there does seem to some confusion about PC Gamma, but he is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. Actually, he does mention that the RGB data will be stored and transmitted in nonlinear form. The paper is about the debate over whether the alpha data should also be nonlinearly encoded (for uniformity), or not. He also mentions another great debate in computer graphics: whether partially-transparent pixels should have their alpha already multiplied into the RGB values, or whether alpha should be independent. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He does mention it applying to the RGB data. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. To know whether he supported Timo, you'd have to ask him. He's talking about using a linear representation in one very particular place, not commenting on Timo's obsession with everything being linear everywhere. Linear and nonlinear representations both have their place. Dave |
#226
|
|||
|
|||
Mike Engles writes:
Actually, Alvy has a number of mistakes in that paper. I'm still not sure if he understands gamma encoding... Yes there does seem to some confusion about PC Gamma, but he is absolutly clear about the need for linear processing. As for not understanding Gamma encoding, that is not clear from the article. Actually, he does mention that the RGB data will be stored and transmitted in nonlinear form. The paper is about the debate over whether the alpha data should also be nonlinearly encoded (for uniformity), or not. He also mentions another great debate in computer graphics: whether partially-transparent pixels should have their alpha already multiplied into the RGB values, or whether alpha should be independent. He has been around a long time, and does know a thing or two. If gamma encoding were that important he would have mentioned it. He does mention it applying to the RGB data. Suffice to say that he and his collaborator are MAJOR digital graphics imaging authorities who on the face of it supports Timo Autiokari's lonely stance. His last words in the gamma article are telling. To know whether he supported Timo, you'd have to ask him. He's talking about using a linear representation in one very particular place, not commenting on Timo's obsession with everything being linear everywhere. Linear and nonlinear representations both have their place. Dave |
#227
|
|||
|
|||
"Mike Russell" writes:
. In this 1995 article, Alvy states: "Nonlinearity should never be stored in an image. Or, if it is, then this nonlinearity must be noted in the storage format in such a way that it is known how to remove it to retrieve linear data." Right. All you need to satisfy the above is a way to decode the pixels back to linear space. PNG has that. OpenEXR stores pixels in a version of floating point - but the decoding method is specified. sRGB also specifies how to convert between linear and encoded pixels. Looks like this problem is mostly solved now. Of course, you *can* leave data linear, but you need more bits for it. The Pixar Image Computer, deveoped under Alvy at Pixar, used 12 bits per colour component in memory, and in data files, while arithmetic was all 16/32 bit. As for Timo's lonely stance - he appears to be in good company now, having been debunked together with Alvy Ray Smith and Dan Margulis, all in the space of a few days. :-) Shall we then place George Preddy above all the others you mention? If being debunked is a virtue... Dave |
#228
|
|||
|
|||
Mike Engles writes:
Believe it or not, this was the way it was done 20 years ago, but the idea got lost along the way, leading to the mess described in this memo. Unfortunately, it is probably too late to change. The technique offered here is the best that can be done short of changing all the hardware." There's more to the history than that. Computer graphics started out using 8-bit linear images, because it was simple and obvious. Television started out using analog gamma-corrected voltages, because there were a bunch of good reasons to put the gamma correction in the camera instead of in the receiver. But along the way, computers started generating television signals, and digitizing television, and television itself became digital, and then photography came along and borrowed from all of these. It seems that there was a differnt way and the only people who use it now are the scientists. The vast majority of digital images in existence are probably 8-bit "gamma corrected" data, because that's a particular sweet spot that makes a good tradeoff between cost and results. But there are people working with fixed-point linear data and floating-point linear data, and people who store one way and process the other. Dave |
#229
|
|||
|
|||
what's RGB?
Aerticeus "digiboy" wrote in message om... the surprise to me about color management is thats its a suprise to everyone else. I've always thought that the task of converting different gamuts, white points, phosphers etc too much for the average / typical user. How do you color manage when you have perceptive colors like RGB, color mixed output colors like CMYK and fixed-by-dye colors like Pantones, all on the same page? Can't be done! How do you manage out of gamut colors. Shrink the gamut, and if the image moves to a device with a larger gamut, what happens then? Do you shrink a gamut by chromaticity ie shrink towards the white point, or do you do it so the perceptual colors are the same? Just my 2p worth. I have color management turned off DB |
#230
|
|||
|
|||
On Wed, 01 Dec 2004 01:39:24 GMT, "Aerticeus"
wrote: what's RGB? Aerticeus Red, Green, Blue? Like what your monitor uses. -- Bill Funk Change "g" to "a" |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sony Cybershot P100 VX '640x480' movie mode is fake | Mark Elkington | Digital Photography | 17 | November 2nd 04 01:24 AM |
What's the D300's "Close-up mode" for? | Darryl | Digital Photography | 10 | September 23rd 04 05:11 PM |
Q-Confused about which picture record mode to use in a digital camera. | Mr. Rather B. Beachen | Digital Photography | 1 | July 13th 04 01:50 AM |
What image quality mode to use? | Mr. Rather B. Beachen | Digital Photography | 2 | July 13th 04 01:21 AM |
wireless 550EX in manual mode with 420EX | danny | Other Photographic Equipment | 1 | February 15th 04 03:35 PM |