Re: [Gimp-developer] GIMP color-management spec and further discussion
Martin Nordholts wrote: On 02/07/2010 04:55 AM, Omari Stephens wrote: 1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. I don't think we should assume that, do you have an example use case where that is a good idea? I think the best guess is sRGB, assuming a file that was produced by a legacy device. Which were (back then) to be viewed on monitors with a profile similar to sRGB. Another source for images of these kind are web developers who want to achieve consistent colors cross a web page -- the rationale beeing: if the browser has no color profile information, the colors may be wrong, but at least consistent. Among garden-variety photo labs, it's pretty much standard to discard any color profile information and just assume sRGB. I think we should rather assume the image is in the working space color space. The user's choice of a working space does not reveal any information about an unknown image. I don't think the chosen working space should be used as input for import heuristics. My thinking is that it is the same working space color profile that is used for the GIMP color picker and also for images without a color profile attached. So when you pick RGB 128,128,128 in the GIMP color picker and open an image with no color profile, RGB 128, 128, 128 in the image will be displayed the same as RGB 128,128,128 in the GIMP color picker. OK, the color picker's colors must match, of course. Probably that means that the color picker can't show any numbers as long it's not yet clear which color space it will be assigned to. Or, perhaps better: the color picker gets disabled when no image is open. But the same problem still occurs when switching between images with different working color spaces. The very same color may have different RGB values in different color spaces. Assuming a calibrated monitor, the color picker displays absolute colors, so i think the RGB values should change, not the colors. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GIMP color-management spec and further discussion
I had composed a response, and then shortly before sending, WIFI on my laptop conked out. I think yahvuu covered most of what I was going to say, though. I'll send it anyway when I pull the laptop out again. --xsdg On 02/10/2010 07:09 PM, yahvuu wrote: Martin Nordholts wrote: On 02/07/2010 04:55 AM, Omari Stephens wrote: 1) When an image is opened with no associated color profile, we assume that it is encoded in sRGB space. I don't think we should assume that, do you have an example use case where that is a good idea? I think the best guess is sRGB, assuming a file that was produced by a legacy device. Which were (back then) to be viewed on monitors with a profile similar to sRGB. Another source for images of these kind are web developers who want to achieve consistent colors cross a web page -- the rationale beeing: if the browser has no color profile information, the colors may be wrong, but at least consistent. Among garden-variety photo labs, it's pretty much standard to discard any color profile information and just assume sRGB. I think we should rather assume the image is in the working space color space. The user's choice of a working space does not reveal any information about an unknown image. I don't think the chosen working space should be used as input for import heuristics. My thinking is that it is the same working space color profile that is used for the GIMP color picker and also for images without a color profile attached. So when you pick RGB 128,128,128 in the GIMP color picker and open an image with no color profile, RGB 128, 128, 128 in the image will be displayed the same as RGB 128,128,128 in the GIMP color picker. OK, the color picker's colors must match, of course. Probably that means that the color picker can't show any numbers as long it's not yet clear which color space it will be assigned to. Or, perhaps better: the color picker gets disabled when no image is open. But the same problem still occurs when switching between images with different working color spaces. The very same color may have different RGB values in different color spaces. Assuming a calibrated monitor, the color picker displays absolute colors, so i think the RGB values should change, not the colors. regards, yahvuu ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Hybrid window mode
On 2010-02-08 00:40, Damien de Lemeny-Makedone wrote: I'm so sad this proposal did not trigger any further discussion. I really think that concurrent modes design is a mistake. It does not [cut] I think one of the reasons for this is that your emails are treated as spam by Google Gmail. I don't know why... -- SHIRAKAWA Akira ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
