| |||||||||||||
Sobotka: Why GIMP is inadequateSobotka: Why GIMP is inadequatePosted Jan 12, 2011 8:38 UTC (Wed) by gowen (guest, #23914)In reply to: Sobotka: Why GIMP is inadequate by tshow Parent article: Sobotka: Why GIMP is inadequate
Consider, for example, a gradient from (0.5f, 0.5f, 0.5f) to (0.6f, 0.6f, 0.6f), or in 8bit hex terms, from $808080 to $9A9A9A. That's a 27 step gradient.It's a 27 step gradient over relatively small change of colour intensity. He's shown a 50 step gradient from WHITE to BLACK. That's not the same thing you are describing. All quantization involves introducing steps -- the question is to determine when those steps are perceptible, and when they are not. Show that 50 steps is too few from 0xFF to 0x00 does not tell us anything about what step size is perceptible from 0x80 to 0x9A.
(Log in to post comments)
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 9:11 UTC (Wed) by farnz (guest, #17727) [Link] Where it becomes important is not when painting afresh, but when editing an image. Take, for example, a bad photograph taken with inadequate lighting, and shadow on an amateur DSLR like the Canon Rebel series (D550 in my part of the world). The sensor has 12 bits of accuracy, or, put differently, 4 to 5 bits I can throw away when trying to fix my mistakes before putting this photo on the web. If I'm working in 16-bit, I can lighten the bits that were hidden in shadow by a small amount (say the equivalent of 2 bits), and then enhance contrast image-wide, costing me the equivalent of 3 bits of accuracy. Because I started with 12 bits, my resulting, visually improved image has between 7 and 9 bits of accuracy - when I downconvert to 8-bit for final output, I get 7 to 8 bits of accuracy; some people may notice this in the areas that were shadowy, but it's no longer that bad. Now do the same process with an 8-bit image. I throw away 2 bits in the shadowy areas, leaving 6. I throw away up to 3 bits improving contrast, making the bits in shadow have just 3 bits of accuracy in the range 0x00 to 0xff. That makes the image look bad. This is part of why photographers disagree on why it's needed; a better photographer would have got a decent exposure in the first place, one that didn't need quite so much fiddling to make it look good. I'm no expert, so I get a bad exposure of a well-composed scene, and have to play to make it look good (fortunately, my current tool of choice, digiKam, works in 16-bit, and gives me the adjustments I need to fix things).
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:05 UTC (Wed) by dgm (subscriber, #49227) [Link]
Lighten 2 bits means multiplying the channel value by four, making the pixel 4 times more bright. It doesn't sound like an small amount to me.
Also, I don't have the algorithm for contrast enhancement in mind, but 3 seems quite a lot to me.
I do retouch amateur pictures with Gimp. Worse, I usually start with a JPEG, not raw, and I would swear that the output looks far much better than 3 bits per channel (that's 9 bits per pixel). Maybe you are losing some color information, but 15 bits? no way.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:08 UTC (Wed) by farnz (guest, #17727) [Link] I'm rescuing bad exposures that wouldn't be usable at all if not retouched from RAW. These are not subtle improvements; I'm still not a good enough photographer to get the exposure almost right first time. If I were working with JPEGs, I'd just have to discard the exposure entirely, no matter that it's the only one where I got the composition right. It's simple things like catching a reflection of the sun in an otherwise dark composition, resulting in the swan (that then chooses to fly off) being too dark, and the duck in the shade being virtually invisible. Now, you can argue that I should have made better use of the camera, and got an exposure where the sunlight reflecting on the metal object is overexposed, but the rest of the exposure is good, and I'd not disagree. I need to get better at using the tools I have in the field, not just fixing it up later. But the fact remains that I didn't manage that: I got an exposure with 12 bits per channel from the sensor; of those 12 bits, for most of the image, only the lowest 7 to 9 bits per channel are actually interesting data, except in the area that reflected the setting sun, where it's the top bits that are interesting data. By working in 16 bits per channel while I'm fixing my mistakes, I get to recover an otherwise lost exposure; if I were limited to 8 bpc, the major corrections I need to make will also trash the image.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 18:44 UTC (Wed) by dgm (subscriber, #49227) [Link]
Then you're clearly outside of the Gimp current capabilities. Fortunately that doesn't mean you're out of options.
You could use ImageMagick, that uses internally floating point operations, to create semi-enhanced versions, and then make the final combination with the Gimp or some of the many HDR tools out there.
Another option is, of course, waiting until GEGL gets fully integrated in the Gimp.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 19:50 UTC (Wed) by farnz (guest, #17727) [Link] I've never claimed to be out of options; for my needs, digiKam is powerful enough - and for the cases where it isn't powerful enough on its own, digiKam to get me a good 8 bpc source, then Gimp to fix the remaining defects (unfortunate spots on people, that tiny bit of light that makes it look like my father in law has a boil on his nose, the spaghetti sauce stain on the tablecloth etc) is an amazing combination, especially given the price. I'm just giving a real example of why 8 bits per channel isn't enough for all amateur uses of computer image editing; given that my needs stray into the high bit depth world from time to time, I can easily understand why a professional would sometimes need high bit depth. And, of course, extending your final point, if I really, really need Gimp to be the ultimate editing tool for my images, I can do things to help get GEGL fully integrated. Maybe I work on it myself, as I'm a programmer. Maybe I pay someone to get it in there, if I were a rich man. Maybe I make sure that there are bugs for all the limitations in Gimp that affect me, and I follow them and help with testing (including learning enough sysadmin stuff to build versions from git). The joy of Free Software here is that I'm not quite as stuck as I would be with proprietary software.
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 21:39 UTC (Tue) by daniel (subscriber, #3181) [Link]
"Then you're clearly outside of the Gimp current capabilities. Fortunately that doesn't mean you're out of options."
Upgrading to GIMP 2.6.11 for example, which supports 32 bits per channel?
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 13:42 UTC (Wed) by tshow (subscriber, #6411) [Link]
> It's a 27 step gradient over relatively small change of colour intensity. He's shown a 50 step gradient from WHITE to BLACK. That's not the same thing you are describing. All quantization involves introducing steps -- the question is to determine when those steps are perceptible, and when they are not. Show that 50 steps is too few from 0xFF to 0x00 does not tell us anything about what step size is perceptible from 0x80 to 0x9A.
The article's example is bad, but the problem is real, and it's one I have run into repeatedly in practice; that's why I gave you the $80 to $9A example. Throw a few gradients with that level of stepping on a few translucent layers, and the banding starts to get very noticeable. Dithering helps, mind you.
As a regular gimp user, higher color depth isn't the highest priority thing on my wish list; you can work around the color depth if you have to. It would be nice not to have to work around the problem any more, however.
|
|||||||||||||