Re: GUI Bugs: Levels and Curves
On Tue, Mar 14, 2000 at 03:42:29PM -0600, Jon Winters wrote: >123, 123, 123 is a shade of gray >115, 115, 115 is a shade of gray >139, 139, 139 is a shade of gray > >Trust the numbers, they don't lie. Of course they do, if one of these apply: 1. Your film is colour-balanced. 2. Your scanner is colour-balanced. 3. The light isn't even. 4. The Levels thingy in point 1 has destroyed all the grays, just because (e.g.) there was less blue in the shadows than there was red. I'd say that normally _all four_ apply. The numbers lie. The Curves correction is an attempt to make them truthful :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: GUI Bugs: Levels and Curves
>> There appears to be some problems in this algorithm. I'm certainly no colour >> expert, but the weak point seems to be in: >> >> >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) >> >> How can you know that this colour is supposed to be grey, and not a gray with >> a tint of blue, for instance? The problem is finding what is supposed to be >> exactly gray :-) >> >> The other problem seems to be that you'll lose some precision, but hopefully >> it's not more than a bit or perhaps two. >> >> For the UI adjustments, I'll leave that to the others :-) Hi Steinar, In fact you never really know what the correct colors in a photo should be unless you have a known point of reference (like a color or grayscale card in the photo). Even so, the lighting conditions may be such that the color card is no longer relevant. Nevertheless, you can often look at a photo and see that it is not quite right. When this happens you can experiment with adjusting the colors so that certain measured pixels in the image are forced to be neutral (that is, gray). For most photos of normal scenes it is often very easy to identify parts that "should" be gray: road surfaces, car wheel rims, other steel objects, etc. Adjusting the color of these parts of the image to a neutral value often makes the whole image look much better (for examples, you can see Chapter 6 of Grokking the GIMP, in particular the parts at http://gimp-savvy.com/BOOK/node60.html and following -- but you may need to wait for the slashdot effect to subside first ;-). Also, keep in mind that color correction is largely a function of the artist's perception. In the original scene, gray objects may not appear gray at all due to the spectrum of the illumination. However, the artist's objective is not necessarily to make the image appear as it did when photographed. Often it is to produce an image which looks like it was taken under "natural" or "studio" lighting conditions (but not always). Carey Bunks Dr. Carey Bunks Senior Scientist BBN Corp. 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
Re: GUI Bugs: Levels and Curves
On Tue, 14 Mar 2000, Steinar H. Gunderson wrote: > Uwe, > > There appears to be some problems in this algorithm. I'm certainly no colour > expert, but the weak point seems to be in: > > >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) > > How can you know that this colour is supposed to be grey, and not a gray with > a tint of blue, for instance? The problem is finding what is supposed to be > exactly gray :-) No problemo... 123, 123, 123 is a shade of gray 115, 115, 115 is a shade of gray 139, 139, 139 is a shade of gray Trust the numbers, they don't lie. -- Jon Winters http://www.obscurasite.com/ "Everybody loves the GIMP!" http://www.gimp.org/
Re: GUI Bugs: Levels and Curves
Uwe, There appears to be some problems in this algorithm. I'm certainly no colour expert, but the weak point seems to be in: >2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) How can you know that this colour is supposed to be grey, and not a gray with a tint of blue, for instance? The problem is finding what is supposed to be exactly gray :-) The other problem seems to be that you'll lose some precision, but hopefully it's not more than a bit or perhaps two. For the UI adjustments, I'll leave that to the others :-) /* Steinar */ -- Homepage: http://members.xoom.com/sneeze/
Re: GUI Bugs: Levels and Curves
>> I just tried to mimik some algorithm for enhancing the colors of an image taken >> by a digital camera (or a scanner, or ...) that was explained for photoshop >> (and works very well -- far better than the automatic). By trying this I found >> some things that have to be discussed (and maybe later reported as errors). >> But first I describe the algorithm. It is taken from an excerpt of a book >> about color correction: >> >> http://www.daton.de/wargalla/(german) >> auf dieser Seite gibt es einen Link zu "das BUCH" und dort diesen >> Algorithmus als Probekapitel >> >> 1. make the level of each channel (R, G, B -- _not_ RGB or value) spread from >> the beginning of the hills to their end (don't know the right english words) >> >> 2. take a color pick of some point that has to be gray (say: 123 / 115 / 139) >> >> 3. adjust the curves for each channel (again R, G, B, -- _not_ value) with >> only one aditional point, that all three values meet the middle one (123 >> in the example): R 123 -> 123, G 115 -> 123, B 139 -> 123 >> >> Hope this was clear enough to be valuable. These techniques are described in detail in "Grokking the GIMP" sections 6.1 and 6.2. See: http://gimp-savvy.com/BOOK/node60.html http://gimp-savvy.com/BOOK/node61.html >> >> The problems that arise: >> >> - for levels and curves there are four channels R, G, B, value. Is the fourth >> one really "value" (from HSV) or is it the combination of the other three?? >> The latter one is called "RGB" in photoshop and I think this is clearer. Yes, the fourth one is really value; the functional form is V=max(R,G,B). This is the same as what's produced by the Decompose function (found in the Image:Image/Mode menu) when used with the HSV option. >> - in curves it is not easy to discover what is the input (x or y) that is >> matched by the shown curve to the output. As someone a little bit familiar >> with maths, I can determine that x is input and y output but maybe it would >> be better to give these two terms directly (or are there problems with i18n >> strings in a picture?) I suspect that you are using GIMP version 1.0.4 which has no feedback about the mouse position in the Curves tool dialog. The developers' version of the GIMP has fixed this by providing a positional information field which gives the exact mouse position in the Curves tool dialog while manipulating the curve. Again, this is explained in detail in section 6.2 of "Grokking the GIMP". >> - if the other two points are really bugs this one is not and though has to be >> delayed after 1.2: >> It would be very nice to enter the value for x (input) and y (output) >> numerical and not by carfully driving the mouse. Photoshop has (albeit since >> 5.0) two entrys that show up if a point from the curve is selected. I agree that this would be a nice feature. For this to work with multiple control points on a control curve there needs to be the notion of the "active" control point which shouldn't be too hard to implement. Carey Bunks Dr. Carey Bunks Senior Scientist BBN Corp. 70 Fawcett St, 15/2A Cambridge, MA 02138 tel: 617-873-3028 fax: 617-873-2918 email: [EMAIL PROTECTED]
