Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
On 12 August 2010 03:19, Rupert Weber wrote: > Disclaimer: I am not a color buff. Anybody who actually *knows* about > that stuff, please chime in. I'm hardly a color buff either, but I'm going to chime in with a related query: My understanding of GEGL (and, I assume, a fully GEGL-based GIMP) is that colors will be represented internally as linear-light RGB(A) structures. Given that (and please correct me if I'm already veering off track), how are the red, green and blue illuminants defined? Are they "virtual colors" that lie far enough outside the visible gamut that they can completely contain it? Or are they something else, like standard sRGB illuminants, or illuminants related to the color-space defined for the image being edited? Apologies if this is all laid out in a road-map or API document somewhere - I've looked and come up blank. Regards, Ed. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
On Thu, Aug 12, 2010 at 7:24 AM, Alexia Death wrote: > On Wednesday, August 11, 2010 06:04:36 David Gowers wrote: >> On Wed, Aug 11, 2010 at 12:12 PM, David Gowers <00a...@gmail.com> wrote: >> > On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR >> > wrote: GIMP is a jerk (I get >> > cases where I draw a curve and the middle of it gets flattened into a >> > straight line); But I haven't been painting anything with GIMP >> > recently so I don't know whether it's also a jerk with XAA. >> >> It is. Looks like I have a bug to file. > Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale > ends up with pressure 0. And I have a vague memory thats fixed somewhere in > development pipeline. I have the fixed version already.(0.10.8) Believe me, after experiencing THAT problem, I would know about it. Generally that problem resulted in the stroke ending and no more drawing until I eased off on the pressure. This is a different bug (and, MyPaint also uses the GTK+ input code and does NOT experience this bug at all no matter how fast I move) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
> Disclaimer: I am not a color buff. Anybody who actually *knows* about > that stuff, please chime in. > > PAL/SECAM vs sRGB > = > While writing the Lab/LCH layer mode stuff, I wondered so far why the > result is still slightly different from the current GEGL implementation > of Color/Hue/Saturation/Value modes. > > Now after taking a quick peek at the babl source, it seems that > GEGL/babl assumes a PAL/SECAM RGB space as source (just like the > Decompose plug-in.) > > Considering that two different implementations use PAL/SECAM, I am > wondering if there is a good reason for it and I just don't understand; > or if maybe they just either copied from each other or happened to > reference the same (limited) resource? > After all, accurate color conversion information isn't abundant and was > probably less so when that code was written. sRGB has only been around since 1996. I suspect that the gimp version dates from before that, or at least before sRGB came into common use. > So far I'd say it's a bug -- barring actual color management the most > reasonable assumption seems to be sRGB. > I don't think we want our color profiles to affect layer blending, so I think it is best that we choose a single color space and stick with it. My intuition(possibly wrong) is that when LAB is only used as a temporary calculation space (as in layer blending) the RGB color space used will make only a very small difference in results as long as the RGB and LAB white points match up (ie RGB(255,255,255) => L*a*b*(100,0,0)). This would leave speed, compatibility, and legacy support as the primary reason to choose a particular RGB color space. > D50 vs D65 > == > Another question during transformation to Lab is, which illuminant or > reference white to use. > > That part, I don't quite understand yet. Does that depend on the source > data, or simply on how the monitor is calibrated? > You would not use the monitor white point, but you might want to use the white point of the image's color space or D50 depending on what you are trying to accomplish. For a convenient color space to do math in use the source image's white point. For data interchange use D50 (as photoshop and ICC profiles do). Jay Cox jay...@gimp.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] 2.7.3 Performance
On Wednesday, August 11, 2010 06:04:36 David Gowers wrote: > On Wed, Aug 11, 2010 at 12:12 PM, David Gowers <00a...@gmail.com> wrote: > > On Wed, Aug 11, 2010 at 10:25 AM, GSR - FR > > wrote: GIMP is a jerk (I get > > cases where I draw a curve and the middle of it gets flattened into a > > straight line); But I haven't been painting anything with GIMP > > recently so I don't know whether it's also a jerk with XAA. > > It is. Looks like I have a bug to file. Not with GIMP. Its a bug in the wacom driver. Top end of the pressure scale ends up with pressure 0. And I have a vague memory thats fixed somewhere in development pipeline. -- Alexia. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Hi, On 11.08.2010 19:19, Rupert Weber wrote: > PAL/SECAM vs sRGB > = > While writing the Lab/LCH layer mode stuff, I wondered so far why the > result is still slightly different from the current GEGL implementation > of Color/Hue/Saturation/Value modes. > > Now after taking a quick peek at the babl source, it seems that > GEGL/babl assumes a PAL/SECAM RGB space as source (just like the > Decompose plug-in.) that sounds a bit strange to me. I thought PAL uses something like luminance channel plus 2 chroma channels? (See section 10.1 in [1] for a definition of PAL) Possibly you've run into a linear light RGB vs. gamma-corrected RGB issue?!? > [..] -- barring actual color management the most > reasonable assumption seems to be sRGB. Me, too, thinks that sRGB is a reasonable assumption. If you want to Do It Right(tm), you will have to take the image's color profile into account. Since most, if not all 8-bit implementations of color operations are agnostic of the current color space, however, i think it's valid to postpone full color space support until GEGLized processing takes over. > D50 vs D65 > == > Another question during transformation to Lab is, which illuminant or > reference white to use. As far as layer modes are concerned, you are actually free to choose. If i understand correctly, you're on a chase for the 'best' 'color' layer mode anyway (where 'best' refers to some subjective quality). All other things being equal, it doesn't hurt to conform to the industry standard aka photoshop, which uses D50 [2]. Explanation from [2]: "" Lab values do not define absolute colors unless the white point is also specified. "" Often, in practice, the white point is assumed to follow a standard and is not "" explicitly stated Which means, if you import or export Lab data you need to know the whitepoint to interpret to the data correctly. Layer modes, in contrast, are used purely internally, so the chosen whitepoint doesn't really matter here. regards, yahvuu [1] http://www.poynton.com/PDFs/coloureq.pdf [2] http://en.wikipedia.org/wiki/CIELAB ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Rupert Weber (g...@leguanease.org) wrote: > D50 vs D65 > == > Another question during transformation to Lab is, which illuminant or > reference white to use. > > That part, I don't quite understand yet. Does that depend on the source > data, or simply on how the monitor is calibrated? Well, Lab as a color space is not fully defined. Without further information it is not possible to have a Lab color calculated back to e.g. sRGB. The problem is, that the "white" in Lab (100%, 0, 0) has no absolute color coordinates. You don't know if this is a reddish white of a light bulb or the blueish white of a fluorescent tube. In that sense Lab is not an absolute color space, unless you define what you actually mean by "white". So if you have a sRGB image (where sRGB defines D65 as the white point) you can easily transform this into an Lab image, but you need to attach the information "the "white" is actually D65" to the result, to be able to meaningfully be able to transform the image back. Maybe this helps a bit, Simon -- si...@budig.de http://simon.budig.de/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Lab conversion, GEGL, RGB space, Illuminant
Disclaimer: I am not a color buff. Anybody who actually *knows* about that stuff, please chime in. PAL/SECAM vs sRGB = While writing the Lab/LCH layer mode stuff, I wondered so far why the result is still slightly different from the current GEGL implementation of Color/Hue/Saturation/Value modes. Now after taking a quick peek at the babl source, it seems that GEGL/babl assumes a PAL/SECAM RGB space as source (just like the Decompose plug-in.) Considering that two different implementations use PAL/SECAM, I am wondering if there is a good reason for it and I just don't understand; or if maybe they just either copied from each other or happened to reference the same (limited) resource? After all, accurate color conversion information isn't abundant and was probably less so when that code was written. So far I'd say it's a bug -- barring actual color management the most reasonable assumption seems to be sRGB. D50 vs D65 == Another question during transformation to Lab is, which illuminant or reference white to use. That part, I don't quite understand yet. Does that depend on the source data, or simply on how the monitor is calibrated? I'll be grateful for any enlightenment. Rupert ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer