| |||||||||||||
Sobotka: Why GIMP is inadequateSobotka: Why GIMP is inadequatePosted Jan 11, 2011 15:24 UTC (Tue) by gowen (guest, #23914)In reply to: Sobotka: Why GIMP is inadequate by cantsin Parent article: Sobotka: Why GIMP is inadequate
As a keen amateur photographer, shooting with a Canon DSLR, I've never felt the need for 16 bit RGB.
It's interesting that the author talks about posterization at 8-bit, but demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why would someone do this?
He then add "Pundits that suggest this is negotiable are simply and flagrantly incorrect[2]" -- a footnote that leads to absolute no supporting evidence of our incorrectness.
Yes, certain specialised applications need higher bit depths, and yes, the gamma correction in GIMP could be considerably better, but overall this article adds literally nothing to the debate. He doesn't show us the better results of higher bit applications, just repeats the same old talking points. (And of course, everything he writes about 8-bits-per-channel is true about 12-bits-per-channel, and he makes no effort to demonstrate "12 is good enough"). The Pantone system, quantizes everything onto about 3000 spot colours, but no-one talks about the quantization effects of that.
(Log in to post comments)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 15:36 UTC (Tue) by boudewijn (subscriber, #14185) [Link] One Krita hacker, Dmitry Kazakov, is also a keen amateur photographer and he agrees with you. On the other hand, Martin Reynolds of MyPaint shows that there's advantage of 16 bit/channel when painting in http://mypaint.intilinux.com/?p=19. And in the final analysis, if my camera or scanner can produce 12 (or 16) bits/channel, and my expensive monitor (wish I had one) can show 12 (or 16) bits/channel, then it would be a pity not to keep all that precision, I guess.
eight bits... Posted Jan 11, 2011 15:45 UTC (Tue) by nettings (subscriber, #429) [Link]
...might be ok if you don't do very much with your image. the problem is you're going to apply a number of transformations, and then rounding errors accumulate.
take a look at an image histogram after changing the black and white points in colors->curves. that is data loss at work (a particularly graphic case, i admit). why should i put up with gaping holes in my histogram if the original image had 10 or 12 bits of depth?
the discussion is pretty much the same as with cd audio quality. a carefully mastered and dithered cd is capable of totally adequate sound quality. but its underlying format, 16bits at 44k1 sampling rate, is woefully inadequate for studio use. so what everyone does is work at higher bitdepths and possibly higher sampling rate, and only down-convert as a very last step, before the product goes out to the consumer.
eight bits... Posted Jan 11, 2011 18:24 UTC (Tue) by Imroy (guest, #62286) [Link]
> The problem is you're going to apply a number of transformations, and then rounding errors accumulate.
It's not just rounding errors. If you're dealing with an image using a wide colour gamut, you need the extra precision to properly represent the large colour space. Posterization will result if using 8-bit components with a wide colour gamut.
> A carefully mastered and dithered cd is capable of totally adequate sound quality. but its underlying format, 16bits at 44k1 sampling rate, is woefully inadequate for studio use.
It's important to distinguish between what is adequate for source material and temporary/intermediate results, versus the final output. For the latter, 8-bit sRGB (or CD-Audio) is indeed adequate most of the time. But if you pull that into an editor you may soon have problems from posterization (lack of precision), out-of-gamut colours, blown highlights, lost shadow detail, low resolution, etc.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 16:37 UTC (Tue) by welinder (guest, #4699) [Link]
> It's interesting that the author talks about posterization at 8-bit, but
> demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why > would someone do this?
It demonstrates the problem using two small on-screen images.
One operation always causes me to hit the 8 bit limit. If I have an
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 16:56 UTC (Tue) by gowen (guest, #23914) [Link] It demonstrates the problem using two small on-screen images. If 6 bits is not enough there, then clearly 8 bits is not going to cut it on anything you print.And if 8 bits is not going to cut it, then 10 bits can hardly be any better. And if 10 bits is not good enough, how can we expect 12 to be? And if ... well you get the idea. Your argument is not valid. If you want to convince me, show, don't tell.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:32 UTC (Tue) by nye (guest, #51576) [Link]
>If you want to convince me, show, don't tell.
Given that 8 bits per channel is the most that can be displayed by the average monitor, how exactly do you propose to demonstrate the problem?
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 17:51 UTC (Tue) by prokoudine (guest, #41788) [Link]
> Given that 8 bits per channel is the most that can be displayed by the
> average monitor, how exactly do you propose to demonstrate the problem?
Just check histogram after editing. You get hair-comb after levels and curves in 8bpc.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:11 UTC (Tue) by drag (subscriber, #31333) [Link]
Yes.
People hating the 8-bit limit has little to do with displaying colors on your monitor, unless they are just parroting. The 8-bit limit comes into play when it comes to _processing_ your images.
You can see it any time you want with Gimp if you play around with multiple layers and run a few filters. Before long you'll start seeing visual artifacts start showing up. Colors that are wrong, weird L-shaped artifacts, lots of graininess, and errors that look like the sort of things you get from highly compressed jpeg images.
One of the nice things about digital art is the ability to twist and deconstruct images to make new images. Like how you can take audio samples of every day things, manipulate them, and make music out of things.
With just 8-bits then this makes the process a lot more time consuming, depending on what your aiming for.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 11:21 UTC (Wed) by nye (guest, #51576) [Link]
>People hating the 8-bit limit has little to do with displaying colors on your monitor, unless they are just parroting. The 8-bit limit comes into play when it comes to _processing_ your images.
Indeed. To be clear, I was addressing the complaint that the article should have more convincingly shown the problem, which struck me as unfair.
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:36 UTC (Tue) by foom (subscriber, #14868) [Link]
Good monitors support 8 bits/color output. Average ones only support 6 bits. Bad ones only support 6 bits, and don't do dithering. And there's a whole lot of bad ones out there. Surprisingly, you can even find them in Macs, which makes Apple's excessive use of gradient effects in OSX's UI look really crappy.
You can tell if you have a bad screen just by pulling down a menu, and look at the gradient shadow effect on the edge. You will see horrible banding. If you look at the screen from an angle, it's even more obvious (vertically usually works better). On an "average" display, you can see the dithering effect if you really look, but it isn't nearly so bad.
Oops, sorry for the diversion/rant. :)
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 21:51 UTC (Tue) by boudewijn (subscriber, #14185) [Link]
And some utterly drool-worthy monitors and graphics cards support 12 or even 16 bits... And I so wish someone with one of those monitors could check Krita to see whether the support I hacked in for those cards and monitors actually works correctly...
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 12:40 UTC (Wed) by romanfi (guest, #72329) [Link]
nye wrote:
> Given that 8 bits per channel is the most that can be
You can always look at the histogram.
And probably you want to do that after converting between color profiles, esp. wide gamut profiles like ROMM (Kodak ProPhotoRGB), esp. when you need such color spaces when you do a lot of transformations.
Of course, the average image can easily be handled fine with 8 bits. And the average digitial camera writing JPEGs also delivers no more than that, but who wants to be average?
Sobotka: Why GIMP is inadequate Posted Jan 18, 2011 21:07 UTC (Tue) by daniel (subscriber, #3181) [Link]
"And if 8 bits is not going to cut it, then 10 bits can hardly be any better"
Depends on whether you consider two binary orders of magnitude "hardly" vs "massive" (I take the latter view).
Sobotka: Why GIMP is inadequate Posted Jan 11, 2011 18:14 UTC (Tue) by tshow (subscriber, #6411) [Link]
> It's interesting that the author talks about posterization at 8-bit, but demonstrates it with a 50-level gradation (i.e. less-than-6-bit). Why would someone do this?
Because you only get all 8 bits of range if your endpoints are black and white, respectively. The place where low bit-depth bites you is in subtle gradients; the closer the endpoints are, the fewer steps you have.
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.
You also lose precision when you blend gradients between layers.
Sobotka: Why GIMP is inadequate Posted Jan 12, 2011 8:38 UTC (Wed) by gowen (guest, #23914) [Link] 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.
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.
|
|||||||||||||