Re: [Gimp-developer] [Gegl-developer] babl roadmap
On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries In other words, you will make a list of all operations that don't work in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. As a maxim for guiding GIMP development, consistent results for the same property values / slider positions reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code. 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 10/14/2014 08:50 AM, Simon Budig wrote: for conversions between RGB working spaces there is no fundamental distinction between XYZ and unbounded linear gamma sRGB. There is one fundamental difference between XYZ as the real PCS and sRGB as PCS (those are scare quotes; the terminology sRGB as PCS is misleading at best): Worked out step by step: It takes one matrix multiplication to get from UserRGB to XYZ. The required matrix A is contained in the UsrRGB ICC profile colorants. It takes a second matrix multiplication to get from XYZ to sRGB. The required matrix C is the inverse of the matrix contained in the sRGB ICC profile colorants. A and C are both defined in terms of XYZ. Once you have matrix A for getting from UserRGB to XYZ and matrix C for getting from XYZ to sRGB, you can concantenate the two multiplications into one matrix multiplication. This is because matrix multiplication is associative: C*(A*B) = (C*A)*B, where B is the UserRGB RGB values that will be converted to sRGB (linearized RGB data is assumed). One matrix multiplication or two, you still get to the same place. But the required one matrix to multiply first has to be *calculated* using *two* matrices, both of which are defined in terms of the real PCS, which is XYZ. Then you have to store the result of C*A in memory for future use. Pippin wants to go through sRGB as PCS to get to XYZ. In a sane color-managed editing application, it takes one matrix multiplication to get from UserRGB to XYZ, using matrix A. In Pippin's sRGB as PCS, first you convert from UserRGB to sRGB using the matrix that's the product of C*A, that you've previously stored somewhere in memory. Then you convert from sRGB to XYZ using the inverse of C. Two conversions. Which of course can in turn be concantenated into one multiplication and also stored in memory for future use. Kind regards, 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
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On Fri, Oct 17, 2014 at 12:01 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/16/2014 03:37 PM, Øyvind Kolås wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries In other words, you will make a list of all operations that don't work in unbounded sRGB, and then you will convert from unbounded sRGB to UserRGB for those operations, and then back to unbounded sRGB. Good luck with that. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. As a maxim for guiding GIMP development, consistent results for the same property values / slider positions reflects a profound failure to understand the nature of RGB image editing and can only lead to bad code. No I am explaining how we will start out making these changes for engineering reasons. How to follow a process that doesn't destabilize and destroy what we already have. While your back-seat driving, asking about detailed choices of side-roads 4 weeks from now on our road-trip is not very productive when we're not even sure we'll be in the country of those roads you want us to take – or if we will have swapped the hummer for a jeep. ___ 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
In the current babl/GEGL/GIMP code base, I counted five files that contain functions that require a conversion from RGB to XYZ: 1. gimp/plug-ins/common/decompose.c 2. gimp/plug-ins/common/compose.c 3. gimp/app/core/gimpimage-convert-type.c 4. gegl/operations/common/image-compare.c 5. gegl/operations/common/noise-cie-lch.c These five files use the babl file: babl/extensions/CIE.c The babl/extensions/CIE.c code calculates the sRGB to XYZ matrix M, starting from the D65 unadapted sRGB color space red, green, blue, and white xy values. Calculating M from xy values is a fairly complicated process. Study the equations on http://brucelindbloom.com/index.html?Eqn_RGB_XYZ_Matrix.html and make sure to read note 2, which says Be careful that reference whites are used consistently. For example, sRGB is defined relative to a D65 reference white and ICC profiles are defined relative to a D50 reference white. Mismatched reference whites must be accounted for elsewhere, typically by using a chromatic adaptation algorithm. In an ICC profile D50-adapted color-managed workflow, you don't use the unadapted D65 sRGB M (that the babl code calculates) to get from sRGB to XYZ. In an ICC profile color-managed workflow, you don't need to calculate the D50-adapted M for a matrix RGB working space, because you can read M directly from the ICC profile colorants. There are two ways to fix the conversion to XYZ code in babl/extensions/CIE.c: 1. babl/extensions/CIE.c can be rewritten to use D50-adapted M retrieved directly from the UserRGB ICC profile colorants. Then convert to XYZ. 2. Or else you can use sRGB as PCS, which allows you to rewrite the code in babl/extensions/CIE.c to use hard-coded D50-adapted sRGB M. In this case: i. Upon opening an image, first retrieve M from UserRGB (call this matrix A). ii. Then retrieve M from sRGB and calculate the inverse (call this matrix C). iii. Then calculate C*A and store this information in memory as D. iv. Then convert from UserRGB to unbounded sRGB using the matrix D. v. Then convert from unbounded sRGB to XYZ using the hard-coded D50-adapted sRGB M. In an ICC profile color-managed workflow, sRGB is just another ICC working space profile. It doesn't need special treatment. The right way to fix the babl conversion to XYZ is to rewrite babl/extensions/CIE.c to use M taken from the UserRGB ICC profile colorants. And forget about sRGB as PCS. There may be a problem somewhere in the GIMP code for which sRGB as PCS might be a solution. Converting to XYZ is not one of those problems. Kind regards, 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
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Unfortunately for hard-coded sRGB as PCS, the ICC profile specifications are a moving target. Right now the ICC profile illuminant is always D50. But in the next planned release of new specifications, things will change: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. iccMAX is a radically different approach which builds on ICC v4 but enables a far more flexible means of connecting devices, data, materials, observers and illuminants. //end quote I would ask every babl/GEGL/GIMP developer who cares about GIMP as a high end ICC profile color-managed image editor to read the rest of the page that I just linked to, and maybe think long and hard about whether you really want to limit yourself to babl color management based on hard-coded D50-adapted sRGB as PCS. D65 unadapted sRGB is based on CRT technology that is no longer in widespread use. Rec.2020 is the up and coming new display device standard. D50-adapted ICC profiles are based on profile specifications that revolve around increasing outdated print-based technologies. Print-making technologies have changed, and today the output device is just as (or more) likely to be a display screen. The ICC is moving forward (and let's hope they also fix a few issues that V4 introduced). Tying GIMP to sRGB as PCS is a dead-end move. Kind regards, 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
Re: [Gimp-developer] [Gegl-developer] babl roadmap
Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. 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 10/17/2014 06:39 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. Kind regards, 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 Fri, Oct 17, 2014 at 12:47 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø ___ 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/17/2014 06:39 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: //begin quote from http://color.org/DevCon/devcon14.xalter While this fixed PCS is capable of delivering unambiguous color transforms, it cannot support the increasing demand for spectrally-based reproduction. [...] Tying GIMP to sRGB as PCS is a dead-end move. If you take spectrally based reproduction as an argument against sRGB as PCS you should be at least be so fair to also mention that *any* RGB based image editing is bound to fail for this. In point of fact, I've already said thist. But I'm happy to say it again. RGB data is not spectral data. I know. Which is why your previous mail could have had the very same text and the following sentence as the conclusion: Tying GIMP to RGB based editing is a dead-end move. Which is exactly the dead end you have been advocating a lot in the recent discussion. 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 Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? ___ 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/17/2014 07:08 AM, Øyvind Kolås wrote: On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? I did not ask people to study spectral color management. I did ask people to realize that the ICC profile specs are changing. In particular, D50 will no longer be the only profile illuminant. The point of this endless discussion is that unbounded sRGB is a singularly bad way to forcibly recast the user's RGB data for RGB image editing. The code for converting to unbounded sRGB isn't yet in place. At present, to get right results from babl/GEGL/GIMP, it would suffice to replace hard-coded sRGB Y and XYZ with UserRGB's Y and XYZ, and correct the babl code that converts to XYZ. And of course it should be easy for the artist to switch at will between perceptually uniform and linear RGB. For the very few RGB editing operations that really must be done using the sRGB primaries, write special code as appropriate and label the operations in the UI as sRGB only so the user knows what's happening. The babl roadmap lays out a plan to complicate the existing code, apparently only to turn around and straighten it out again. 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 Fri, Oct 17, 2014 at 1:39 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 07:08 AM, Øyvind Kolås wrote: On Fri, Oct 17, 2014 at 1:06 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/17/2014 06:59 AM, Øyvind Kolås wrote: As a former researcher at a national color science laboratory, and a major contributor to babl and GEGL; I probably have no idea about these things – and how the spectral data in named color ICCv4 profiles might be used. https://www.youtube.com/watch?v=vKpaXu87Coo /Ø Nobody doubts your intelligence, acumen, or accomplishments. Not even me. Then what is the purpose of continuing to endlessly perpetuate this discussion, asking people to read about spectral color management, when our roadmaps barely have good colorimetric management in scope? For the sake of argument alone? The point of this endless discussion is that unbounded sRGB is a singularly bad way to forcibly recast the user's RGB data for RGB image editing. The code for converting to unbounded sRGB isn't yet in place. The babl roadmap lays out a plan to complicate the existing code, apparently only to turn around and straighten it out again. What you see as complicating the existing code is normal when one does something known as refactoring, the roadmap documents the road towards the goal – and isn't even a complete roadmap since we don't know all we will know when we are further along on it. http://en.wikipedia.org/wiki/Code_refactoring GIMP is not the only project using GEGL; nor is it the only user interface on top of GEGL. GEGL pipelines need to be able to deal with arbitrary counts of RGB spaces; which also GIMP need for having multiple project use open and doing cross project copy-paste, clone etc. One of the other GEGL UIs is this http://libregraphicsworld.org/blog/entry/artificial-intelligence-designs-websites-uses-open-technology-stack /Ø ___ 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 10/14/2014 07:16 AM, Øyvind Kolås wrote: 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: 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? 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. You did pick the only plausible answer: check the colorants and TRCs. 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. For most users, for most purposes, you as developer can probably decide for the user that slight off means close enough. The trouble is you don't know whether slight off is a mistake or intentional. The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants. The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved. And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK. 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?
Elle, It is not the critic who counts; not the man who points out how the strong man stumbles, or where the doer of deeds could have done them better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood; who strives valiantly; who errs, who comes short again and again, because there is no effort without error and shortcoming; but who does actually strive to do the deeds; who knows great enthusiasms, the great devotions; who spends himself in a worthy cause; who at the best knows in the end the triumph of high achievement, and who at the worst, if he fails, at least fails while daring greatly, so that his place shall never be with those cold and timid souls who neither know victory nor defeat. - Theodore Roosevelt Time for you to stop making vaguely patronising remarks and make an actionable suggestion, or leave this. Hugs and positivity, Ed -Original Message- From: Elle Stone Sent: Friday, October 17, 2014 4:43 PM Cc: gegl-developer-list ; Gimp-developer Subject: Re: [Gimp-developer] [Gegl-developer] babl roadmap: How do you know which images are sRGB images? On 10/14/2014 07:16 AM, Øyvind Kolås wrote: 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: 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? 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. You did pick the only plausible answer: check the colorants and TRCs. 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. For most users, for most purposes, you as developer can probably decide for the user that slight off means close enough. The trouble is you don't know whether slight off is a mistake or intentional. The profile maker might have used something other than Bradford adaptation to make the profile. This is allowed by the ICC specs, and would result in slightly different colorants. The artist might be fully aware that the profile is not exactly like the GIMP built-in profile, and nonetheless intend to use the embedded sRGB profile instead of the GIMP built-in sRGB profile. Perhaps the existing gray axis needs to be preserved. And so on. You think it's OK to second-guess and decide for the artist what happens to the artist's RGB data. But it's really not OK. 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 ___ 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/15/2014 01:46 PM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: On 10/15/2014 08:30 AM, Øyvind Kolås wrote: On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB? As you very well know we don't *have* the specific list of editing operations you ask for. I don't know why you keep repeating the question. You seem to think that not getting an answer to that question proves a point, but I definitely have no idea what the point is. You make a very fair point. A better way to ask my question would have been By what criteria will the devs decide whether an RGB operation should use sRGB primaries instead of UserRGB primaries? The babl roadmap says gamma slider and multiply compositing will be done using UserRGB. The roadmap's implied criteria for which RGB operations use sRGB primaries seems to be If it works in unbounded sRGB, use sRGB primaries; otherwise use UserRGB primaries. If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work. Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? For RGB editing operations, use UserRGB primaries except in the rare cases for which only sRGB primaries will work. Kind regards, 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 Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/15/2014 01:46 PM, Simon Budig wrote: If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work. Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it. /Ø ___ 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 16 October 2014 21:37, Øyvind Kolås pip...@gimp.org wrote: On Thu, Oct 16, 2014 at 6:52 PM, Elle Stone ellest...@ninedegreesbelow.com wrote: On 10/15/2014 01:46 PM, Simon Budig wrote: If I understand them correctly, Michael Henning and Jon Norby are saying that the criteria is something along the lines of: For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work. Is there in fact general agreement among the devs that the criteria for deciding when to use sRGB primaries instead of UserRGB primaries is approximately as follows? Once we have the vocabulary to also describe this aspect of the pixelformats used by operations, the first thing we should do is to annotate all the operations which are broken when done with sRGB primaries, then we will be able to continue refactoring, profiling and optimizing; without breaking existing functionality/rendering. Not only in terms of making more operations request directly userRGB, but also doing things like make some linear operations accept any of userRGB or bablRGB (or other linear RGB); and creating output buffers in the same format – to avoid unnecessary conversions in such cases. Using a fixed linear RGB format instead of userRGB is what for some operations will provide the consistent results for the same property values / slider positions. Knowing which operations this is important for is easier to determine when we have code providing the vocabulary in babl. The further along on the roadmap, more of the road will have to be laid/determined as we walk it. Hi pippin, you are answering in detail 'how we will get there' but Elle (as I see it) is asking more 'do you agree that we want to go there'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different there in mind, or if you think it is too early to decide this. There being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.' -- Jon Nordby - www.jonnor.com ___ 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 Fri, Oct 17, 2014 at 12:49 AM, Jon Nordby jono...@gmail.com wrote: you are answering in detail 'how we will get there' but Elle (as I see it) is asking more 'do you agree that we want to go there'. This leaves me unsure if you are implicitly agreeing, if you disagree and have a different there in mind, or if you think it is too early to decide this. There being the goal that *eventually* in GEGL 'For RGB editing operations, use UserRGB primaries *unless* there's a really, really good reason why only sRGB primaries will work.' All of the above. I'm stating in detail how we will get as far as I can see into the future; which will bring us closer to there. As well as reasons it probably will not a be binary choice when we have more knowledge of the capabilities and constraints. The level of detail of the roadmap is in places already too high as it both tries to document an intermediate state as well as hint at where we possibly want to go from there - and bits of what it documents will probably already be invalid by the time much of it is in place. /Ø ___ 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 08:50 AM, Simon Budig wrote: Elle Stone (ellest...@ninedegreesbelow.com) wrote: 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. Whether or not the roadmap calls for converting non-sRGB images to unbounded sRGB will determine what kind of code is written going forward. In an ICC profile color-managed workflow, sRGB is just another RGB working space, requiring no special treatment. The babl roadmap sRGB as PCS/fooRGB is a proposed solution to perceived problems. The problems for which sRGB as PCS/fooRGB might be a solution are things like: *Reducing computing overhead for 8-bit sRGB image editing. *Accomodating legacy sRGB XCF files. *Accomodating legacy sRGB only file formats. Solving legacy and 8-bit sRGB overhead problems does not require converting ICC profile color-managed images from fooRGB to unbounded sRGB. 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 When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB? This isn't just an implementation detail. The answer to this question will determine the path for writing code going forward. To restate the question yet again: Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing? Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries? 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 Wed, Oct 15, 2014 at 2:11 PM, Elle Stone When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB? This isn't just an implementation detail. The answer to this question will determine the path for writing code going forward. To restate the question yet again: If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ. At all points we know the CIE Lab or XYZ coordinates of all involved pixels – and we aim to do as few conversions as possible (never converting the actual data to either bablRGB or XYZ, even temporarily - unless requested.) Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing? Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries? There is no plan to maintain lists in the end, this information would be self-contained within each individual operation, like whether the operation needs CIE Lab, pre-multiplied alpha or not or even an 16bit linear grayscale. This automatic data representation conversion is an inherent abstraction and property both of GeglBuffer and the services provided for op authors to make implementing consistently behaving operations easy. /Ø ___ 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/15/2014 08:30 AM, Øyvind Kolås wrote: On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone wrote: Will all color-managed image editing be done using the user's chosen primaries, with absolutely no conversions to unbounded sRGB for image editing? Or are the developers committing themselves to maintaining lists of which operations should be done using fooRGB primaries and which should be done using sRGB primaries? There is no plan to maintain lists in the end, this information would be self-contained within each individual operation, If each individual operation will carry information about whether the operation should use fooRGB primaries or sRGB primaries, then at some point someone must compile a list for the devs to consult. Unless you really mean to say: *DevA working on Op1 decides whether to use fooRGB primaries or sRGB primaries for Op1. *DevB working on Op2 decides whether to use fooRGB primaries or sRGB primaries for Op2. *DevC can decide DevA and DevB were both wrong and change the code. And so on. Consider the following: 1. RGB editing operations performed on fooRGB images using fooRGB primaries are *always* correct. 2. More than half of all operations on linear RGB are chromaticity-dependent. Many more than half of all operations on perceptually encoded RGB are chromaticity-dependent. *All* of these operations WILL produce *wrong* results after the image is converted to unbounded sRGB. So the developer choices are: 1. Either don't convert fooRGB images to unbounded sRGB for *any* RGB editing operations. Results will *always* be right. 2. Or else compile a list of all editing operations that do work and don't work in unbounded sRGB, and only convert the image to unbounded sRGB for the operations that do work in unbounded sRGB. And hope you get the list right, because you are messing with the user's RGB data for no good reason. I will ask again: For which specific RGB editing operations do you plan to convert the image from fooRGB to unbounded sRGB before performing the operation? Either the answer is None. For color-managed fooRGB images, all RGB operations will be done on data encoded using fooRGB primaries. Or you are committing the devs to maintaining a formal or ad hoc list of operations on fooRGB data vs operations on unbounded sRGB data. And then you are committing the devs to writing per op code to implement entirely pointless conversions from fooRGB to unbounded sRGB and back again. 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
Elle Stone (ellest...@ninedegreesbelow.com) wrote: On 10/15/2014 08:30 AM, Øyvind Kolås wrote: On Wed, Oct 15, 2014 at 2:11 PM, Elle Stone When the user opens a color-managed fooRGB image, for which *specific* editing operations will the image be converted to unbounded sRGB? If the user is putting a text-layer, which has been rendered using cairo and is in 8bit sRGB premultiplied alpha. The compositing of this with preceding data in the layer stack the babl-format of the output buffer of the over/normal compositing operation, as well as the data fetched from both buffer inputs - would likely be RaGaBaA float - if the two linear inputs differ. I'm not sure why your text-layer stack example is relevant to my very direct and still unanswered question. As you very well know we don't *have* the specific list of editing operations you ask for. I don't know why you keep repeating the question. You seem to think that not getting an answer to that question proves a point, but I definitely have no idea what the point is. What would be the benefit of having such a list? If the implementor of an operation thinks, that an operation needs to work in unbounded bablRGB then it will request bablRGB input and gegl/babl will do its work to provide that. An example *could* be an operation that does change the warmth of an image by simulating lighting by a different illuminant. The operation could request bablRGB input data, convert that to XYZ internally, do the shift, convert back to bablRGB and provide that as output. But then the author might be better off with requesting the data in XYZ directly, saving him from the work of doing the bablRGB to XYZ conversion: Gegl/Babl does that for him. Both ways are fine, Gegl/Babl can do this today. It is up to the author to choose and it will be *completely* transparent to the user of the operation. This is completely independent from how the image pixels are stored in memory, even when they are stored with a different set of RGB primaries. Gegl/babl in that case will know how to transform the stored pixels into bablRGB the operation requests, and they'll know what to do with the output. The text example from pippin is supposed to illustrate that Gegl in real world situations has to deal with external sources which are beyond the control of Gimp. And Gegl/Babl provide the facilities to deal with that. At all points we know the CIE Lab or XYZ coordinates of all involved pixels You don't know the XYZ coordinates until you actually convert from fooRGB to XYZ. Likewise with CIELAB. So it's not clear what the above sentence really means. If you know the pixel values of a pixel and know how to convert fooRGB to XYZ there is absolutely no need to do the actual conversion. You can still claim that you know the XYZ as well as CIELAB coordinates. You just don't bother to do the conversion until you really need it. If you know that x is 5 and you know how to calculate the square of a given value you don't need to do the actual calculation. Yet you still know in the sense that the specific value is available to you as soon as you need it. But here's a maxim for *RGB* image editing: For RGB editing operations, don't ever, ever, ever convert color-managed fooRGB to unbounded sRGB. I assume that by RGB editing operations you're referring to the math-centric ones which bluntly apply a mathematical formula to the pixel data, not caring if the operation makes sense from a colorimetric/physics based viewpoint. (Examples would be multiply or even levels on the RGB channels). We now have operations who utterly need to know the colorimetric values of a pixel, because they are based on color theory. Shifting the color temperature of an image might be a good example. We have to be able to mix these operations, because Future Gimp (TM) will head towards non-destructive editing, where the user uses the UI to construct a graph of operations to combine all the image sources to get to the desired result. We don't intend to stick to the have-an-image, do-an-operation, have-a-new-image, repeat paradigm. So we need infrastructure that can mix both, the colorimetric and the math-centric approach. Your proposal of never-ever-converting will make real colorimetric operations a pain, since the color-temperature operation has to accept the fooRGB data, convert it to XYZ, do its operation and convert back to fooRGB, because fooRGB is ultimately what is needed for a potential next math-centric operation. With the infrastructure proposed by pippin the math-centric operations will ask for fooRGB data as input and provide fooRGB data as output. That means that chaining them together will neatly avoid colorspace conversions. If the user then decides to put a color-temperature change in the mix (lets assume it requests bablRGB as input and provides bablRGB as output, since the author decided against XYZ for some reason) Gegl/Babl will put a fooRGB-bablRGB conversion into the
Re: [Gimp-developer] [Gegl-developer] babl roadmap
On 10/15/2014 01:58 PM, Michael Henning wrote: Yes, the majority of operations will operate in myfavoriteRGB space, but you seem to be operating under the premise that absolutely *no* filters can possibly exist that require a specific color space to function properly. This isn't the case. Actually, I did go through the code base as thoroughly as possible, and I did identify various editing operations that depend on the data being in specific color spaces (not always D50-adapted sRGB). See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html Take, for example, the color blindness simulation in gimp. This filter tries to simulate color blindness so that artists can create images that look good to people who are color blind. An operation like this should not change based on which working space you choose to edit in; it must always try to be as faithful to colorblindness as possible. For an operation like this, being able to specify the working space on the developer's side is a must. Otherwise, it can't work properly. This is one of the operations that I identified. I also noted that ALL such operations should be clearly identified as such in the UI. While operations like that might not be too common, it should still be physically possible to create them. Before you say okay, so a proper icc color managed editor will convert between icc profiles, what's the big deal?, realize this: babl is exactly the mechanism that we are using to make that happen. These background conversions that you seem to hate so passionately The background conversions that I was objecting to two years ago convert between perceptually uniform and linear gamma RGB data, using the sRGB TRC as a stand-in for true perceptual uniformity. Those are the babl/babl/base/util.h TRC flips. I do recognize (now, but not two years ago) the point of the TRC flips. The point is to be able to flip instantly between linear gamma and perceptually uniform RGB. See http://ninedegreesbelow.com/gimpgit/gimp-hard-coded-sRGB.html#best-solution In my working copies of babl/GEGL/GIMP I have the babl TRC flips disabled because the ways in which the user can choose perceptual vs linear encoding are not transparent and also subject to change. But I'm looking forward to having the UI make it easy for the user to be able to switch at will. Assuming the devs will allow the user the freedom to make such choices. are exactly the same conversions that you already admitted were necessary when copying and pasting between images. Just because conversions shouldn't be common does not mean they should be impossible, or removed altogether. I've already said elsewhere in this thread that how you get from RGB to XYZ/LAB/etc is really irrelevant as long as the end result is correct. The same thing applies to conversions from one set of RGB primaries to another set of RGB primaries. Also, given a bug in current LCMS conversions between RGB matrix profiles, I would rather babl did the conversions. See http://sourceforge.net/p/lcms/mailman/message/32834352/ But even when that particular LCMS bug is fixed, there doesn't seem to be any advantage to calling on LCMS to do simple matrix conversions. The only real drawback to all of the above is I can't see any way a GIMP user can edit their images in an RGB *LUT* color space. From my own point of view, that would never be a concern. But it should be noted that babl/GEGL/GIMP does seem to have this one requirement. It should be noted that such cases as the colorblind filter and the old device-based code should be treated as explicit exceptions, labelled in the UI. The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries. Kind regards, 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
Am Mittwoch, 15. Oktober 2014, 15:37:01 schrieb Elle Stone: [...] The guiding principle should be that except in these carefully bracketed and clearly identified cases, the *user* controls the RGB working space, and all RGB editing operations should use the user's chosen primaries. It seems this is the central point. The choice of bablRGB (or linear sRGB or linear Rec709) is merely an implementation detail and only works as the base transformation matrices are calculated on. Think of it as bablXYZ. It's the common ground babl does its color transformations on, just like ICC uses XYZ. This however is not the working space used in the gegl tree and therefore in GIMP. Just as applications using ICC internally don't work on XYZ data. The reason why babl uses bablRGB instead of XYZ is just so that the common case of using sRGB data that is coming from the outside world (pippin gave the example of text rendered by cairo) can be used directly and doesn't need a conversion step. Code making use of the babl functions is free to keep every imported buffer in its native color space (probably linearized) and the system will make sure that the data is treated the right way when a conversion is required (for example when merging layers -- which format would win is probably a point to be discussed later). At least that's how I understood the situation. Kind regards, Elle Stone Tobias signature.asc Description: This is a digitally signed message part. ___ 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
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 ___ 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 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 ___ 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 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. 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 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
On Tue, Oct 14, 2014 at 9:04 AM, Simon Budig si...@budig.de 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
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
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
+1 On 14 October 2014 15:54, Simon Budig si...@budig.de 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
On Tue, Oct 14, 2014 at 9:54 AM, Simon Budig si...@budig.de 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
Hi, On Tue, Oct 14, 2014 at 3:58 PM, Thorsten Stettin thorsten.stet...@gmail.com 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 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. /Ø ___ 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/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. ___ 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
