On Sun, Mar 16, 2014 at 10:22 PM, Elle Stone <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: > On 03/14/2014 10:34 AM, Øyvind Kolås wrote: >> >> On Fri, Mar 14, 2014 at 2:21 PM, Elle Stone >> <ellestone@xxxxxxxxxxxxxxxxxxxx> wrote: >>> >>> But a >>> patch to LCMS for more than four inks is surely possible. Doing soft spectral spot color proofing, might be outside the scope of LCMS2, or the resulting data might end up being prepared and baked into ICC profiles using LCMS for the pre-separated output. >> The code *experiment* linked to has nothing to do with ink limiting; >> what I linked to is rather naive additive and subtractive color mixing >> in a 20 band spectral color space, a little bit like how physics >> works. But yes; as I noted it doesn't take into account subsurface >> scattering and other things that ICC profiles try to encompass >> indirectly. > > My apologies. Clearly I didn't read the code carefully enough. > > That's a question for the ArgyllCMS mailing list. People on that list > profile all kinds of very odd things for specialized print reproduction, > including rock specimens, tile samples, and oil paints. I doubt any of them > would describe the process as "easy". Note that spectral measurements of spot colors is also used for standards based spot color soft proofing, see http://color.org/CxF_test.xalter . In a future GIMP with ink/plate targeting capabilities; it would be reasonable to let the operator experiment with adding and removing/rearranging inks interactively in GIMP; and some suitable good GEGL op is used for previewing purposes (some of these options; might already want meta data about the spot colors encoded in a passed in profile.). > https://mail.gnome.org/archives/gimp-developer-list/2012-August/msg00084.html >> >> for an older writeup I did on the topic of GEGL and color. > > I read your writeup several times over when you first posted it and also > recently. But I'm not sure I understand it. Below is a summary of what I > think your writeup means in terms of an image-editing workflow using GIMP: > > 1. When a user opens an image: > a. If there isn't an embedded ICC profile, sRGB is assigned. The user > has the option to assign a different ICC profile. > b. If there is an embedded ICC profile, to cover cases where the > embedded ICC profile is incorrect, the user has the option to assign a > different ICC profile. The same conversation to a babl managed pixel format applies on import. Though we might be loading the data in the native representation and only later turn it to a babl managed pixel format (these are also spaces we can deal with ourselves on the GPU) using a GEGL operation, or even an implicit conversion with ICC profiles managed by a babl-extension. For a composition of multiple source images; these ICC profile settings might vary per asset; and you want to be able to tweak some of it after the initial import/load. When using GIMP 2.9 in 8bit mode; implicit babl conversions keep turning the data 32bit as explained below. > 2. Once the initial ICC profile assignment is taken care of: > a. The image precision is promoted to 32-bit floating point R'G'B'A > (32-bit floating point gamma). > b. The image is converted to the regular sRGB color space. > c. As the conversion is done using LCMS2 unbounded mode, no colors are > clipped during the conversion. Instead, out-of-gamut colors are expressed > using RGB values such that one or more of R, G, and B are less than 0 and/or > greater than 1. > > 3. Although the image really is in the regular sRGB color space, all editing > is done in a linear light version of the sRGB color space, which ensures > that colors blend correctly: > a. If certain layer blending operations look wrong when blended using > the 32-bit floating point *gamma* precision, the user can opt to use 32-bit > floating point *linear* precision (32-bit floating point RGBA). > b. Some operations (for example painting with a brush and Gaussian > blur) are always done using linear light, regardless of whether the image is > converted to linear or to gamma floating point precision. Yes, as image data flows through the GEGL processing graph - the generated temporary output buffers end up being in the preferred working pixel format of the operation. If all your operations used in a pipeline are have "CIE Lab float" as their desired working/output space, there would be only one implicit conversion to CIE Lab at the beginning - no conversions between the operations since the data is already in the desired format. And then an implicit conversion to the desired reading format of for instance a PNG exporting op. Most of the operations in GEGL generate either "RGBA float" or "RaGaBaA float" buffers. > 4. BABL has functions for converting sRGB to LAB, HSV, CMY, etc, for use in > decomposing and composing. Also, babl/gegl/gimp all have functions for > calculating the luminance of an sRGB image. Compose/decompose/calculating > luminance are all done to/from/in linear light sRGB. babl is intended to provide accurate and fast, conversions between a large; and dynamically extended set of pixel formats. It provides a way to register and describe pixel formats (color model, order of components and data types used by components.) and has a reference color conversion engine that goes through double precision floating point linear light sRGB that automatically provides conversions between the pixel formats that can be described. On top of those capabilities; babl has extensions for direct conversions between registered pixel formats; these conversions are checked against the reference at runtime and benchmarked against each other at runtime. Chains of conversions are also checked for accuracy and speed performance. All GeglBuffers are annotated with what BablFormat the pixels within have. The CMYK model in babl as it stands is only intended for annotating that a GeglBuffer contains CMYK; it likely does a really bad job at both decomposing to inks; as well as turning inks to RGB again - it does something though; instead of just giving you black pixels back.). babl also has the abilitiy to deal with indexed/paletted pixels like in GIFs. Where correct using babl for decomposing/recomposing is good - in some cases, like CMYK we'd want GEGL operations that are not using babl but for instance lcms2. > 5. When linear light sRGB is required for an operation: > a. Certain BABL functions "undo" the regular sRGB TRC to create linear > light sRGB. > b. The required editing operations are performed. > c. The image is returned to the regular sRGB color space. > These "to/from linear light" BABL functions include four functions in > /babl/babl/base/util.h: linear_to_gamma_2_2, gamma_2_2_to_linear, > babl_linear_to_gamma_2_2, and babl_gamma_2_2_to_linear. For c. see above, this part is wrong; though in GIMPs case when doing editing in a "gamma" based space; it is true for applying destructive editing operations, but for compositing the layer stack; the data is not returned to 8bpc sRGB until the final result is displayed on screen., The utility functions enumerated are part of the reference conversion (and also used by some of the fast paths). The use in the fast paths is not really clean; since it encourages micro optimizations in the reference code paths; that wouldn't be detected if they cause errors.. but it has the benefit of making all users of the utility functions faster. > 6. Before exporting the edited image, the user can convert the image to the > desired bit depth and ICC color space profile. How and when export profile preferences are configured and managed is open. If we ignore concern of ink separation workflows; it is at export time (as well as during soft proofing) that the data would end up being converted to the desired bit depth and ICC color profile. > 7. At present ICC profile conversions are handled by GIMP, but in the future > they will be handled by GEGL. Some code will likely remain in GIMP, primarily UI related and setting up the processing using GEGL will remain in GIMP, the actual conversions of pixels values would be done by GEGL operations. > A start on GEGL color management is found in > "gegl/operations/external/lcms-from-profile.c". A start on using lcms2 for GEGLs external color management is more correct ;) Internally GEGL uses babl for to provide a way to carry color (and alpha)-management meta data along with the pixels of buffers. > Does my description of the anticipated workflow cohere with what you've > described? Did I get parts/all of it wrong? More correct than wrong. My focus is more on the pipeline than the workflow; the pipeline provides some constraints on which workflows makes sense and which do not. /Øyvind K. _______________________________________________ gegl-developer-list mailing list List address: gegl-developer-list@xxxxxxxxx List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
