Re: IM7 sRGB v4 rendering intent
Posted: 2012-04-18T06:19:34-07:00
I'm not sure the following is flexible enough: How would it handle a stripped image that contains, say, sRGB v4 data which you want to process literally, but convert at the end to another colour profile? To do that, you need something like my suggested -tag or -interpretation, which does more or less what the old -colorspace did (I think).
Not sure of anything yet. Just stirring the pot. Because, however, you already have decided to change what -colorspace does for IM7, a clean break, as suggested in the Developers forum, may be a good idea.
If I understand correctly, IM basically has two "colourspaces" (correct me if I'm wrong): linear RGB(A) and sRGB(A). Again if I understand correctly, all that's needed is a clean way to:
1) navigate between linear RGB(A) and sRGB(A) (this involves two pieces: tagging, and converting.)
2) import into/export from each of them with a profile, ideally with some control over the rendering intent (again, this involves two pieces: tagging, and converting).
(In some cases, explicit tagging is unnecessary, but not always.)
2) could be simplified by deciding to always ICC into and out of as if one is in one of the two "colourspaces", which means that a user who knows what he/she is doing would have to remember to convert back to this one if they're not already, before exporting. Not so good in 8-bit.
I sort of see the attraction of always seeing import and export as two halves of a unit, but I think that there are strong advantages as seeing them as separate operations. I think it's more powerful to see import (or tag)/colorspace and colorspace/export as separate pairs.
An added bonus would have to do with having defaults being reasonably picked when the incoming image does not have an embedded profile, and when writing. However, if one sees profile/colourspace handling as an expert setting, this is not as needed.
Not sure of anything yet. Just stirring the pot. Because, however, you already have decided to change what -colorspace does for IM7, a clean break, as suggested in the Developers forum, may be a good idea.
I think that you basically have a choice of one of three definition "anchors": XYZ, linear RGB, or CMYK. And that things are actually more complicated than that.anthony wrote: Posible solution...
Images that are read with a ICC/ICM profile probably should be marked as having a colorspace of "profile".
That way when you do -colorspace RGB it first converts the colors from the 'profile' to RGB. Later when you do -colorspace 'Profile' it converts back to the colors as per the current profile (whatever that is at that moment).
In this scheme -profile to -profile conversion will ONLY happen if the -colorspace is currently set to 'profile'.
Also in this scheme a ICC profile is ONLY saved if the image is using colorspace 'profile', though I supose it could remain the users responsability to either remove or set the profile right if -colorspace is not set to 'profile' ???
Does this sound reasonable? It should solve quite a few problems, and looks to be mostly backward compatible. That is -profile to -profile conversion still works when it is appropriate, but it links better to the -colorspace image attribute.
Questions: How do profiles list image colors? In terms of XYZ coordinates? I have no idea about the mysterious internals of profiles. Perhaps I don't really need to know!
If I understand correctly, IM basically has two "colourspaces" (correct me if I'm wrong): linear RGB(A) and sRGB(A). Again if I understand correctly, all that's needed is a clean way to:
1) navigate between linear RGB(A) and sRGB(A) (this involves two pieces: tagging, and converting.)
2) import into/export from each of them with a profile, ideally with some control over the rendering intent (again, this involves two pieces: tagging, and converting).
(In some cases, explicit tagging is unnecessary, but not always.)
2) could be simplified by deciding to always ICC into and out of as if one is in one of the two "colourspaces", which means that a user who knows what he/she is doing would have to remember to convert back to this one if they're not already, before exporting. Not so good in 8-bit.
I sort of see the attraction of always seeing import and export as two halves of a unit, but I think that there are strong advantages as seeing them as separate operations. I think it's more powerful to see import (or tag)/colorspace and colorspace/export as separate pairs.
An added bonus would have to do with having defaults being reasonably picked when the incoming image does not have an embedded profile, and when writing. However, if one sees profile/colourspace handling as an expert setting, this is not as needed.
I actually have used some of the alternate colourspaces myself! (How could I forget?)