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
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
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.
Gimp-developer mailing list