[Gegl-developer] babl roadmap ever so slightly updated
A note that the babl roadmap towards enabling use of multiple working/sensor/target RGB spaces in a single GEGL graph has been slightly updated. Now also mentions why accumulating floating point errors if more conversions than desired happens isn't a real concern with current photo technology sensor precision. See https://git.gnome.org/browse/babl/tree/docs/roadmap.txt ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap: How do you know which images are sRGB images?
On 10/13/2014 06:36 PM, Elle Stone wrote: How do you plan to tell when an image is an sRGB image and when it's not an sRGB image? The roadmap specifies 24 different formats for sRGB images and 24 additional formats for non-sRGB images. Presumably the 24 additional formats for non-sRGB images allow GEGL to request, as needed, a conversion of the RGB data from being encoded using sRGB primaries to being encoded using User_RGB primaries and vice versa. Given the 24 additional formats for non-sRGB images, it seems pretty important to be able to detect when the user opens an sRGB image and when the user opens an image that's in some other RGB working space. So again, upon opening an image, how do you plan to detect whether the image is an sRGB image or not? Will you compare MD5 checksums? Will you consult the profile descriptions? Will you examine the profile colorants and TRCs? If you don't understand the context of the question, see the following article: Will the Real sRGB Profile Please Stand Up? (http://ninedegreesbelow.com/photography/srgb-profile-comparison.html) It should be noted that the article doesn't list *all* sRGB profile variants (new ones are being made every day). In particular, the article doesn't list sRGB profile variants distributed with Canon, Nikon, etc proprietary software. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap: How do you know which images are sRGB images?
On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/13/2014 06:36 PM, Elle Stone wrote: How do you plan to tell when an image is an sRGB image and when it's not an sRGB image? The roadmap specifies 24 different formats for sRGB images and 24 additional formats for non-sRGB images. Incorrect, foo and bar a metasyntactical variables; which have a meaning in software development. They are placeholders, babl doesn't know, and shouldn't care what these names/concepts are, the only formats specified in the roadmap are synonyms for the already existing color formats using the sRGB prefix. The ones with foo and bar prefixes are illustrative place-holders, GEGL and other things using babl. Have to choose what different named families of pixel formats mean for their workflows. Presumably the 24 additional formats for non-sRGB images allow GEGL to request, as needed, a conversion of the RGB data from being encoded using sRGB primaries to being encoded using User_RGB primaries and vice versa. There isn't 24 additional formats, but N*12 additional formats, N depending on our needs in GEGL, foo and bar might have been replaced with, compositing, chromaticity, target or other registered classes of RGB for the editing session/pipeline. Given the 24 additional formats for non-sRGB images, it seems pretty important to be able to detect when the user opens an sRGB image and when the user opens an image that's in some other RGB working space. So again, upon opening an image, how do you plan to detect whether the image is an sRGB image or not? Will you compare MD5 checksums? Will you consult the profile descriptions? Will you examine the profile colorants and TRCs? Deciding on this is outside the scope of babls roadmap, since this is something that would have to happen in GEGL or other things using babl. Most likely examination of profile colorants/TRCs since that is what ICC or other color profile meta-data aware image loaders needs to provide down to babl anyways. How the loading code does this; and whether the behavior is configurable in GEGL (without knowing whether it will be end up configurable in GIMP for that reason). In many circumstances it is desirable to to treat almost sRGB as sRGB and consider deviance from the real standard a mistake in labeling; for instance if it is a low bitdepth image containing dithering - at other times assuming that the slight off profile has been applied as is earlier in the production pipeline might be desirable. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap
The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight. If the devs are determined to pursue this course to the bitter end, here are some considerations regarding encoding trc_gamma as double (you really can't do this): //begin quote from the babl roadmap double trc_gamma /* makes sense to have it even if not initially used */ );//end quote ICC RGB working space profile Tone Reproduction Curve information (TRC) can't be held in one double variable unless the TRC really is a true gamma TRC. Some ICC RGB working space profiles have true gamma TRCs. Some ICC RGB working spaces have point curve TRCs specified by varying numbers of points. Some ICC RGB working spaces have TRCs that are specified using parametric curves, which take five parameters. Given that not all profile TRC information can be stored in one double variable, you might consider removing the trc_gamma variable from babl_define_named_rgb_space. A proper TRC retrieving function could be written later, if/when you want to make use of the information. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap
The sRGB as PCS architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail. The babl roadmap says: Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except Luminosity-based BW conversions) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value In addition, Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. The babl roadmap should be amended to include all of the above-listed operations as requiring special-casing in the sRGB as PCS architecture. More than half of the approximately 85 operations that I did check are chromaticity-dependent when performed on linear RGB data. Someone should check all editing operations. You can skip all strictly ADD/SUBTRACT-based operations, including scaling and gaussian blurs. The roadmap says permitting at least linear formats with other chromaticities is highly desirable. It is unclear why permitting should be limited to linear formats. All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform. Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient). Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap
On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: The sRGB as PCS architecture outline in babl/docs/roadmap.txt will likely collapse under its own weight. The roadmap should be amended to reflect a more accurate assessment of the amount of work the planned architecture will entail. The babl roadmap says: Babl currently only supports formats using the sRGB primaries, quite a few editing operations including gamma adjustments and multiply compositing relies on the chromaticities of the space used, permitting at least linear formats with other chromaticities is highly desirable As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL The roadmap says permitting at least linear formats with other chromaticities is highly desirable. It is unclear why permitting should be limited to linear formats. All of the operations listed above depend on the working space chromaticities, regardless of whether the RGB values are linear or perceptually uniform. This has to do with which capabilities one chooses to implement early, since it would bring a functional system, the non sRGB TRC are nice to have but not as fundamental as custom chromaticities. Not having custom TRCs for custom formats; means that those formats would be using the sRGB TRC until such support would be added. Indeed, some (and probably many) operations, that work just fine on linear unbounded sRGB values, are *very* dependent on the chromaticities when performed on perceptually uniform RGB values (for example drawing a gradient). Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying. /Ø ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
Re: [Gegl-developer] babl roadmap
On 10/13/2014 03:25 PM, Øyvind Kolås wrote: On Mon, Oct 13, 2014 at 8:19 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: As the purpose of the roadmap seems to be guiding future development, the list of editing operations that rely on the chromaticities of the RGB working space needs to be expanded. The following list is not complete, but it's a start: The place for this would be in the GIMP wiki; where the state of migration from old type gimp plug-ins to GEGL ops, as well as other tracking state of ops are maintained. http://wiki.gimp.org/wiki/Hacking:Porting_filters_to_GEGL It's OK with me if you put the information in the GIMP wiki. But if you attribute the information to me, please include the disclaimer that I think your architecture will eventually collapse under its own weight. Someone should check all editing operations for perceptually encoded RGB to figure out which operations depend on the chromaticities, and then add these operations to the list of operations that need to be special-cased in the planned sRGB as PCS architecture. The per-op working pixel representation are part of GEGLs design, thus it isn't really special casing - but specifying. You designed an architecture around converting images to unbounded sRGB for editing. After 6 months of trying to show you that your architecture has serious built-in problems, you finally believe me, or at least you believe Mansencal and Sayre. But you want to keep the architecture anyway. So now all chromaticity-dependent editing operations will require a brand new special specifying, unless the image is already an sRGB image. If you didn't intend to convert all images to unbounded sRGB for editing, there wouldn't be any reason to special specify roughly half of all the editing operations that you offer through the GIMP UI. With respect, Elle Stone -- Some operations that require special specifiying, assuming linear encoding: Channel data used as a blending layer Channel data used for making selections Colors/Alien Map HSL Colors/Alien Map RGB Colors/Auto stretch contrast Colors/Auto stretch contrast HSV Colors/Channel Mixer (try Margulis' enhance green formula) Colors/Desaturate average Colors/Desaturate lightness Colors/Mono Mixer (except Luminosity-based BW conversions) Colors/Posterize Colors/Threshold Colors/Levels Gamma slider operations Colors/Levels Red, Green, and Blue Input/Output sliders Colors/Levels Auto Pick (used for white balancing images) Filters/Artistic/Cartoon Filters/Edge Detect/Sobel Filters/Enhance/Red Eye Removal Filters/Noise/HSV Noise Filters/Noise/RGB Noise Filters/Artistic/Soft glow Filters/Artistic/Vignette (any color except gray, white, black) Layer blend Mode/Burn Layer blend Mode/Color Layer blend Mode/Darken only Layer blend Mode/Difference Layer blend Mode/Divide Layer blend Mode/Dodge Layer blend Mode/Hard light Layer blend Mode/Hue Layer blend Mode/Lighten only Layer blend Mode/Multiply Layer blend Mode/Overlay Layer blend Mode/Screen Layer blend Mode/Saturation Layer blend Mode/Value Paint tools depend on the working space chromaticities when using the following blend Modes: Burn, Color, Darken only, Difference, Divide, Dodge, Hard light, Hue, Lighten only, Multiply, Overlay, Saturation, Screen, Soft light, Value. ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] babl roadmap: How do you know which images are sRGB images?
According to the babl roadmap, sRGB images won't need special-case treatment. But every time the user opens an image that isn't an sRGB image, special-case treatment will be required for chromaticity-dependent editing operations. How do you plan to tell when an image is an sRGB image and when it's not an sRGB image? With respect, Elle Stone ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
[Gegl-developer] babl roadmap
The planned architecture as outline in babl/docs/roadmap.txt will likely collapse under its own weight. But if the devs are determined to pursue this course to the bitter end, here are some suggestions regarding white_reference: //begin quote . . . permitting at least linear formats with other chromaticities is highly desirable, this will be fixed by allowing to specify named RGB spaces, possibly like this: void babl_define_named_rgb_space ( Babl *babl, const char *name, double red_xyz[3], double blue_xyz[3], double green_xyz[3], int white_reference, /* could be _XYZ[3] instead of d50/d65/d60; but this is likely sufficient */ double trc_gamma /* makes sense to have it even if not initially used */ );//end quote Short version: You might want to specify white_reference using XYZ[3] instead of using int. You probably want *two* variables: 1. the color space specifications reference white. 2. the ICC profile illuminant. The variable names might be white_reference and profile_illuminant. The D50 profile illuminant tag that's in LCSM and ArgyllCMS profiles has these XYZ values: (0.96420288, 1., 0.82490540). The XYZ values for the D65 sRGB color space specification reference white are (0.950455927, 1.0, 1.089057751). These values are converted from xyY as given in the sRGB color space spec. Long version: 1. Different profile specifications, standards bodies, etc. specify slightly different XYZ/xyY values for D50, D65, etc. And sometimes CMMs and profile makers make up their own D65 values for no apparent reason (http://ninedegreesbelow.com/photography/linux-icc-profiles.html#variants - scroll down to the table labelled Selected D50 and D65 profile white point xyY values). 2. The ICC spec D50 illuminant values are (0.9642, 1.0, 0.8249). These aren't rounded to four places values. These are the actual values given in the ICC spec. 3. ICC profile illuminant XYZ values as found in actual profiles are hexadecimal-rounded. When converted back to decimal, the actual D50 illuminant XYZ values from an LCMS or ArgyllCMS profile are: (0.96420288, 1., 0.82490540). 4. The next release of the ICC specifications likely will allow illuminants other than D50. So assuming LCMS also will support this new functionality, at some point the function babl_define_named_rgb_space will need to directly retrieve the profile illuminant XYZ values. 5. In an ICC profile, the original color space XYZ values have been adapted *from* the color space reference white *to* the ICC profile illuminant. See http://ninedegreesbelow.com/photography/srgb-color-space-to-profile.html 6. In an ICC profile color-managed image editor, you use relative colorimetric conversions between RGB working spaces, so the original color space reference white (for example, D65 for sRGB) is completely irrelevant. With respect, Elle Stone -- http://ninedegreesbelow.com Color management and free/libre photography ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
