|[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]|
W dniu 12-02-07 18:59, Nathan Summers pisze:
On Sat, Feb 4, 2012 at 7:07 PM, Bogdan Szczurek<thebodzio@xxxxxxxxx> wrote:-- cut for brevity's sake :) --As an artist that does a lot of hand drawing i noticed the problems of the 8 bit limit very quickly. Just use the smudge tool and you will see any color, but not the intended colors (rounding errors=new colors). Same goes for the blur brush. Ever tried to to blur larger areas with it? Guess not, since it doesn't work. If the gradient is flat enough it won't blur anymore, since it is just one step away from actually switching a bit in the result. That are very common cases that really would profit from higher color resolutions.Naah ;) you've misunderstood me – I wasn't defending the idea of "8bit as ultimate solution for all", just pointing out that example from linked article was a bit… flimsy ;).Right. This issue is whether "32 bits for all" is right for GIMP's vision statement, or whether it should be one of perhaps several options. I'm not convinced that "32 bits for all" is the right way to go, even though I do think a high end graphics program should offer 32 bits. But there is a lot more to consider than just whether 32 bit floating point offers more precision than other formats. For instance, if you are targeting JPG as your final format, there is probably no practical benefit from working in more than eight bits per channel, since the JPG artifacts will overwhelm the last few bits of eight-bit precision anyway. If your target is eight bit per channel, precision isn't a good argument for 32-bits per channel over 16-bits per channel, since the chances of 16-bit roundoff errors showing up in the final eight bit channel are fairly remote. That said, even when there would be noticeable differences when using a format with higher precision, there may be good reasons for a knowledgeable user to choose to use a lesser-precision data format. Even though the gap has narrowed, integer operations are still significantly faster on modern processors. A user may be happy to trade off some precision in order to do an image operation in fixed point and shave off a lot of time, especially if the target doesn't have an enormous dynamic range anyway. I also think that some on this list have underestimated how important it is for a high-end image application to be able to handle gigantic images. The original GIMP authors went to a lot of work in the transition between 0.60.x and 0.99.x largely in order to support huge images more efficiently. Saying that memory is cheap is not an excuse to be wasteful with it, because data is cheap as well. If program A can handle an image of a certain size on a machine with maxed-out memory, and program B can only handle one of a fourth the size because B insists on converting all images to 32-bits per pixel, which program is the high-end one?
I agree wholeheartedly, especially with the last point! My best! thebodzio _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gimp-developer-list
[Home] [Video For Linux] [Photo] [Yosemite News] [Yosemite Photos] [Yosemite Book Store] [gtk] [GIMP for Windows] [KDE] [Scanner] [Memory] [GEGL] [Gimp's Home] [Gimp on Windows] [Steve's Art] [Webcams]