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] [Gimp-developer] babl roadmap
On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone ellest...@ninedegreesbelow.com wrote: 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. We've acknowledged that chromaticities matter for more than the last half year - and proposed to extend the architecture in ways that doesn't break other parts of the architecture. We change what we have, and avoid fixing what isn'r broken - while trying to address short-coming like you've pointed out. 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. Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not) The PCS used by a CMS is an implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others. /Ø ___ 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] [Gimp-developer] babl roadmap
On 10/14/2014 06:54 AM, Øyvind Kolås wrote: 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. Just like in an ICC based workflow images are converted to unbounded XYZ for editing? (they are not) My apologies, I don't have a clue what you mean by what you just said. But no, XYZ isn't a good color space for image editing, if that is what you are asking. The PCS used by a CMS is an implementation detail; where choices might have been XYZ, linear sRGB or some other linear RGB; of the preceding linear sRGB has nicer properties than any of the others. The above sentence confuses concepts: The babl architecture might require that images to be converted to and from unbounded linear gamma sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB has been turned into a PCS. To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS. Let's cut to the chase: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no? 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
Re: [Gegl-developer] [Gimp-developer] babl roadmap
On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: The above sentence confuses concepts: The babl architecture might require that images to be converted to and from unbounded linear gamma sRGB. That doesn't mean babl is a CMS. And it doesn't mean unbounded linear gamma sRGB has been turned into a PCS. Babls role in the GEGL and thus GIMP architecture is to be the internal CMS; this remains unchanged since babl was split out of a non-linear video editor/compositing system. To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS. I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ. Let's cut to the chase: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? Foo or bar? Do you have any idea what implementation detail means? /pippin ___ 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] [Gimp-developer] babl roadmap
On 10/14/2014 07:52 AM, Øyvind Kolås wrote: On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: To convert images to and from unbounded linear gamma sRGB, you MUST pass through XYZ. XYZ is the PCS. I remind you that linear RGB spaces are a single matrix multiplication away from other linear RGB spaces and XYZ. Matrix conversions between RGB working spaces can be concantenated. That concantenation goes through XYZ. It almost sounds like you want to obscure this fundamental distinction between XYZ and unbounded linear gamma sRGB. Let's cut to the chase: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? Foo or bar? Do you have any idea what implementation detail means? I do know what implementation detail means. You didn't the question, so I'll try again: Are you planning on converting non-sRGB images to unbounded linear gamma sRGB? Yes or no? If yes, are you intending that at least some editing will be done on the image while it's encoded using sRGB primaries? Yes or no? 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
Re: [Gegl-developer] [Gimp-developer] babl roadmap
Hi, I fully agree with Jehan and think it's essential in a healthy software development process to scrutinize and review things. Especially the whole color management stuff is a topic that is not so clear to many of us and - with all my respect to Pippin - depending on a single expert's opinion is a risk in every project. It's natural for this topic that it is also academic. Academic work is the foundation for many things in the computer world, may the hands-on-people like it or not. Perhaps some other color management experts could join in and share their knowledge? One thing could be improved from my point of view: the discussion is spread over the two lists gimp-developer and gegl-developer. As it is all mainly BABL- and GEGL-related it would be more helpful if the discussion took place on a single list. I propose the GEGL-developer list, because this catches both the GEGL-only devs as well as the GIMP devs. Kind regards Sven ___ gegl-developer-list mailing list List address:gegl-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gegl-developer-list
