Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Hi, On Tue, Oct 14, 2014 at 3:58 PM, Thorsten Stettin wrote: > Am 14.10.2014 um 15:04 schrieb Simon Budig: >> >> Hi Thorsten. >> >> Thorsten Stettin (thorsten.stet...@gmail.com) wrote: >>> >>> with all due respect to you, I think you should contribute instead to >>> babble. >> >> If you perceive Elles texts as "babbling" it seems that this discussion >> is way over your head and you might want to consider staying out of it. >> >> Thanks, >> Simon >> > Ok, It pisses me off though. I didn't mean to hurt anybody. > But we don't need any academic discussion. Of course we do! These kind of discussions are really helpful to understand things. Most of these are also over my head (though I wish I understood more of these!) but I am very grateful that they are done in the open! This is also part of what makes a sane Free Software. Now of course, meeting people in LGM or elsewhere is also very good, but that should not prevent the results of these discussions to also be discussed publicly here. Same if it were by phone, I would still always appreciate discussions to be summarized or continued on the mailing list. > We need contribution. Seriously if you don't consider these extremely important contributions for GIMP (discussion on a good architecture for what is essentially the core of GIMP!), I wonder what will be! Of course "code" contributions *too* is nice, but these happen after the discussions in such cases. Anyway please, this is the gimp-developer@ mailing list. If you don't like these discussions about improving the core of GIMP, maybe you are on the wrong list. Also you don't have to read them all! (there are a lot which I don't find interesting just by reading the title, I don't ask people to not write them!). As long as everybody stays polite and remembers we are on a written medium (hence misunderstandings and annoyed feelings are easier to get; when that happens, just breath), please don't interrupt completely on-topic discussions. Thanks. Jehan > Ok, I'm just a packager, sorry for that. > > Cheers > > Thorsten > > > > > -- > Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. > Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. > Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die > Demut. > Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der > Demütige ist fähig zu herrschen. > > ___ > gimp-developer-list mailing list > List address:gimp-developer-list@gnome.org > List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list > List archives: https://mail.gnome.org/archives/gimp-developer-list ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Tue, Oct 14, 2014 at 9:54 AM, Simon Budig wrote: While it certainly could be more concise, the discussion has helped me > tremendously with my glimpse into gegl/babl. So while the > misunderstandings might be easier to overcome within a phone call > keeping the discussion on the list helps with potentially getting the > concepts out there to more people. > People seem to be getting frustrated and I don't think that helps anybody. It seems to me that realigning the conversation in a more appropriate medium would help to make the mailing list discussion more productive. A summary of the phone call would then either bring everyone back together, or continue the dispute on clearer terms. Of course, folks are free to do whatever... $0.02, Chris ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
+1 On 14 October 2014 15:54, Simon Budig wrote: > > While it certainly could be more concise, the discussion has helped me > tremendously with my glimpse into gegl/babl. So while the > misunderstandings might be easier to overcome within a phone call > keeping the discussion on the list helps with potentially getting the > concepts out there to more people. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Am 14.10.2014 um 15:04 schrieb Simon Budig: Hi Thorsten. Thorsten Stettin (thorsten.stet...@gmail.com) wrote: with all due respect to you, I think you should contribute instead to babble. If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it. Thanks, Simon Ok, It pisses me off though. I didn't mean to hurt anybody. But we don't need any academic discussion. We need contribution. Ok, I'm just a packager, sorry for that. Cheers Thorsten -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Christopher Curtis (ccurt...@gmail.com) wrote: > I'll admit that this discussion is way over my head, but as it seems to > involve only two people would it be better handled over a phone call? It > appears that there are some basic assumptions that aren't in alignment. While it certainly could be more concise, the discussion has helped me tremendously with my glimpse into gegl/babl. So while the misunderstandings might be easier to overcome within a phone call keeping the discussion on the list helps with potentially getting the concepts out there to more people. That having said, meeting people in person *is* tremendously helpful and I'd like to extend pippins invitation to the LGM (next year in Toronto) to everybody who is interested in discussing these topics with e.g. pippin and me. There will be funds available to help bring people together. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Tue, Oct 14, 2014 at 9:04 AM, Simon Budig wrote: > If you perceive Elles texts as "babbling" it seems that this discussion > is way over your head and you might want to consider staying out of it. > +1. I'll admit that this discussion is way over my head, but as it seems to involve only two people would it be better handled over a phone call? It appears that there are some basic assumptions that aren't in alignment. Chris ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Hi Thorsten. Thorsten Stettin (thorsten.stet...@gmail.com) wrote: > with all due respect to you, I think you should contribute instead to > babble. If you perceive Elles texts as "babbling" it seems that this discussion is way over your head and you might want to consider staying out of it. Thanks, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Elle Stone (ellest...@ninedegreesbelow.com) wrote: > On 10/14/2014 07:52 AM, Øyvind Kolås wrote: > >On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone > > 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. for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB. In mathematical terms both of these span up a three dimensional vector space (describing color) and the only difference is that they use different basis vectors. You can *easily* describe conversions between different RGB primaries with ulgsRGB as the connecting space (completely replacing XYZ). You would get a different set of transformation matrices of course. XYZ is something that has a special role for all of the non-RGB color spaces Lab, xyY, Luv etc, as well as operations like chromatic adaptation. Hence it makes sense to use it also as the connecting space for the different RGB primaries. > Are you planning on converting non-sRGB images to unbounded linear gamma > sRGB? Yes or no? For pixel storage we will use whatever fits our needs, it does not make sense at this point to specify this. This might be a Lab-buffer with a cache in front of it that has the pixels converted to sRGB. Or a Adobe-RGB-Buffer without a cache. Or unbounded linear gamma sRGB. Or whatever. The important thing is, that gegl/babl provides the means to access these data in whatever format is needed by the operation that is happening. A brightness-invert function might request the data in Lab, do the inversion on the L channel and feed the results back as Lab to the gegl/babl infrastructure, which will process it to provide the next operation in the graph with the input format the next operation needs. > 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? That totally depends on the editing-operation in question and is orthogonal to the pixel memory storage format. Bye, Simon -- si...@budig.de http://simon.budig.de/ ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Hi, Elle, with all due respect to you, I think you should contribute instead to babble. Sorry for that Best regards Thorsten -- Lao-Tse sagt: Nichtstun ist besser, als mit viel Mühe nichts zu schaffen. Und er sagt auch: Ich habe drei Schätze, die ich hüte und hege. Der eine ist die Liebe, der zweite ist die Genügsamkeit, der dritte ist die Demut. Nur der Liebende ist mutig, nur der Genügsame ist großzügig, nur der Demütige ist fähig zu herrschen. ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Tue, Oct 14, 2014 at 1:34 PM, Elle Stone 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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know which images are sRGB images?
On Tue, Oct 14, 2014 at 11:20 AM, Elle Stone 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. /Ø ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Tue, Oct 14, 2014 at 12:34 AM, Elle Stone 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. /Ø ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
Re: [Gimp-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 ___ gimp-developer-list mailing list List address:gimp-developer-list@gnome.org List membership: https://mail.gnome.org/mailman/listinfo/gimp-developer-list List archives: https://mail.gnome.org/archives/gimp-developer-list
