Hi Elle. The following is my understanding, when pippin answers his answers have more authority than mine.
Elle Stone (ellest...@ninedegreesbelow.com) wrote: > Putting aside coding considerations that might affect other software that > uses babl and GEGL, here's my understanding of your current plan for > babl/GEGL/GIMP: A slight preface here. I don't consider it important to focus on the *storage* of the pixel data, as in the actual bulk memory for the pixel data. The important part is, that the data is available to the operations in the format they request upon request. If that is in memory already pre-converted or if that gets converted on the fly is an implementation detail. > 1. Upon opening an image, the image will be converted to unbounded sRGB. I don't think that this is decided yet, I actually consider it unlikely at the moment. I think it might be more likely to have it sitting in memory as userRGB. But again, this is an implementation detail, where I assume that the floating point math is sufficiently precise to avoid visible rounding errors. > 2. For all chromaticity dependent RGB editing operations: > * Either the image will be re-encoded using the user's chosen RGB working > space chromaticities, and then the operation will be performed. > * Or else the image will be converted to CIELAB and then the operation > will be performed. Conceptually the image won't be converted as a whole. A pixel-data-flow-graph will be set up that considers the region of interest. For all chromaticity dependent RGB editing operations the pixels will be re-encoded in the format the operations requests. Which most likely will be userRGB. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. > 3. For all chromaticity *in*dependent RGB editing operations, the image will > be converted to unbounded sRGB for processing. For all chromaticity *in*dependent RGB editing operations the pixels will be converted to the format the operations requests. Which most likely will 0e sRGB or XYZ. And the re-encoding-step can be a NOP, if the previous node in the operations tree already provides the requested format. (Sorry for repeating, but this is an important point: in a given image context "userRGB" really is not conceptually different from sRGB or XYZ, it gets slightly more complicated when two images with different user chromaticies are to be combined.) > 4. When converting to XYZ/CIELAB/etc, the image will first be converted to > unbounded sRGB. Not necessarily. If specific userRGB to XYZ/whatever transforms are available to babl it will make use of them. This will likely be the case for e.g. AdobeRGB. > 5. The GEGL developers will specify on an "operation by operation" basis > whether the operation requires being encoded using UserRGB/Y/etc, or > unbounded sRGB/Y/etc, or CIELAB as a substitute for chromaticity dependent > RGB processing, or etc. It probably will be specified within the implementation. I.e. there won't be a pre-existing separate document with a list for each individual operation. However there might be such a document generated from the implementation. > As an important note, depending on the last operation that was done, the > image might already be encoded using the GEGL-operation-specified format, in > which case a conversion to that format is not needed. Yes, but it is important to keep in mind that we don't sequentially apply one operation after each other, with image-in-memory-steps inbetween. We build a graph of connected operations, where the connections between the nodes will be negotiating the resp. pixel formats. *Then* the pixel data will be fed from the sources into the graph, flow through the graph, have the operations operate on them, potentially converting them to the negotiated pixel formats and finally get sunk into the output (e.g. the node painting into the image view). Bye, Simon -- si...@budig.de http://simon.budig.de/ _______________________________________________ gimp-user-list mailing list List address: firstname.lastname@example.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-user-list List archives: https://mail.gnome.org/archives/gimp-user-list