I don't want to hijack Alexandre's thread with the interesting discussion that started therein, so here's a new thread for it. 2012/1/27 Bogdan Szczurek <thebodzio@xxxxxxxxx>: > W dniu 12-01-27 10:16, Alexandre Prokoudine pisze: >> On Fri, Jan 27, 2012 at 11:01 AM, Martin Nordholts wrote: >>> Images shall always be composed in 32-bit floating point >>> RGBA > > Which RGB? Is it scRGB of GEGL "guts"? :) Hi thebodzio In the end, yes, GIMP's native image data format will likely be 32 bit floating point per component/channel, pre-multiplied linear light RGBA with the same primaries and white point as scRGB (and consequently sRGB). >>> and then have suitable filters and export mechanisms to deal with >>> grayscale and indexed images. > > …and 16 bits per channel… and 8 bits per channel… and bitmaps (1 bit)… and > multichannel… and CMYKs (I wrote some time ago about them on this list)… > > I see two problems with that. > > First is memory use. I'll give an example from my own backyard about > bitmaps. Contrary to what may appear bitmaps are still very important image > mode. At my work I use them as both small and precise means for preparing > and storing scanned pages of old books destined to be reprinted. Given I'll > be compelled to use 32 bits for each pixel I'll practically "waste" 31 bits. > So my images (of course at the time of manipulating them in GIMP) will take > 32 times more space than necessary. It may seem harmless, but take into > account that such bitmaps are oftentimes of sizes about 8000 x 10000 pixels. > Pretty much the same crude calculations are true for other "pixel depths" as > well (8 bits – 4 times, and so on). First, I must point out that your arguments needs to be derived from the GIMP product vision [1], not personal requirements. Saying "I need GIMP to do X" is not a valid argument for adding support for X in GIMP, you need to say "GIMP needs to do X to fulfill the product vision". Otherwise GIMP is doomed to begin (keep?) delivering an inconsistent user experience in some areas. There are two solutions to the memory usage problem: 1. Buy more RAM. GIMP does not need to run well on a 512 MB RAM machine because it is reasonable to expect users of a high-end photo manipulation program to acquire sufficient amounts of RAM. NOTE: I'm not saying GIMP should be wasteful with memory... 2. Make GIMP clever. If GIMP encounters a tile with only values 0.0 and 1.0, the 32 bpc data can be transparently, i.e. without the user noticing, replaced with 1 bpc data. As soon as more bits of precision is required to avoid loss of data, GIMP can transparently convert the tile back to RGBA float. The same kind of optimization can be done for completely black, white and transparent tiles too. Maintaining support in GIMP for an internal image data format of 8 bpc or adding support for an native image data format of 16 bpc is silly because such formats is going to result in rounding errors and lack of HDR support, which is not high-end. > I understand "filters" and "export mechanisms" are to be basically means of > "cramming" information from fp pixels into "less precise" units. It means > it's very probable some information will be lost/distorted. It will happen > in more or less dramatic way, but the problem remains: what tools do we need > to give to user to enable them *complete* and *precise* control over > "conversion" results (meaning: this pixel should have *exactly* this or that > value). When you stick to "image modes" as your paradigm in app itself, you > don't have to worry much about it – user "gets what he sees" (granted he's > into proper CM workflow ;)) or at least have absolute control over sample > values right "on the canvas". Moving this control from "canvas" to "export" > will result in another layer of complexity with (probably) reduced > capabilities for the sake of "simplicity". Most of the time it'll probably > work (much like CM), but I think it'll be a hell to debug and enemy of > marginal, yet important use cases. If you want a pixel to be RGB u8 (128, 90 90) when you export to a PNG8, simply paint that pixel RGB u8 (128, 90 90). There are no problems for RGBA float to represent RGB u8. Maybe I don't fully understand what you mean, could you give a concrete and clear use case that illustrates a problem? / Martin -- My GIMP Blog: http://www.chromecode.com/ "Single-window mode feature complete" _______________________________________________ gimp-developer-list mailing list gimp-developer-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gimp-developer-list
