Re: [Gimp-developer] the Gimp lcms.c plug-in

[Elle Stone <l elle stone gmail com>]

Hi, John,

By "native space" do you mean whatever color space the image happens
to be in when you open it? As per the jpegs generated by my
point-and-shoot are all in the sRGB color space? Or if someone hands
me a file in the AdobeRGB color space, then that file's "native" color
space is AdobeRGB? If this is what you mean by "native color space",
then I agree with you 100% - converting from one color space to
another without a good reason is pointless and can potentially have
bad effects on image integrity.

The "internal working space" I was asking about is something else
altogether. I am under the impression that Gimp either already does,
or is planning to, use a very large internal working space, which
internal working space will be completely beyond the end user's
control.

So the admittedly ambiguous phrase I used, "your internal working
space", was referring to Gimp's internal working space, if in fact
Gimp either already uses, or is planning to use such a thing.
I wasn't referring to whatever working space a user might have
specified in Gimp's color management settings, but I can see how my
wording was ambiguous.

I was hoping for some very brief answers to the following questions:

1. Is my impression correct? Is Gimp planning to use a very large
internal working space for all image manipulation? If the answer is
"No", ignore questions 2, 3, and 4.

2. If so, is that color space something like scRGB mentioned in the
Wikipedia article?

3. If so, what about shadow detail (a problem mentioned in the
Wikipedia article)?

4. If so, will there still be a need for ICC profile conversions (I
can't imagine what the alternative might be, but that doesn't mean
there isn't an alternative) from the image's "native space" (if I
understand your usage of the phrase correctly) to Gimp's very large
internal working space (and back out to whatever output space the user
wants upon exporting the image, and also to display the image on the
monitor screen)?

Elle


On 7/19/12, John Harris <john grynn com> wrote:
> Elle, I am not  a programmer but I am a color professional. so here is
> my input regarding your last question:
>>
>
> It seems to me that you will always need ICC profiles, to convert an
> image from whatever ICC color space profile it happens to be in, to
> your internal working space, and from your internal working space to
> the monitor profile, and from your internal working space back out to
> whatever color space profile the person wants to use to upon exporting
> to a non-xcf file. Yes? No?
>
> "always" is a bit strong.
> Some individuals, such as myself, prefer to do as little profile swapping as
> possible, and in some cases work in complete native spaces during the entire
> flow. Display calibration excluded.
>
> I rarely take an incoming file from it's native space to some other working
> space unless the file needs extreme adjustments. So converting from native
> to working is not a given. There will be some situations where I will send
> the image file directly to the output device without a conversion to the
> output profile. An output profile should be able to be used in soft-proofing
> without the need for conversion to profile. The Adobe workflow refers to
> this as "Preserve RGB".  Having this option allows me and other users to
> proof the output on screen and never convert the file to any profile, thus
> keeping the working file in it's fullest integrity, free of banding, loss of
> color fidelity and other profile related issues that can result from
> remapping.
>
> There may also be times when I will maintain the files native space but
> print using a convert to profile flow, and there are times when I DO convert
> from the native space to a larger space. The latter is often the case when
> the file needs major adjustments for density and contrast. I may also go
> from a larger space, such as ProRGB or Adobe1998 down to sRGB if I am
> working a file that will only see usage on the web and never go to wide
> gamut print.
>
> Feel free to reach out to me with specific questions that might be
> off-topic.
>
> On 07/19/2012 11:12 AM, Elle Stone wrote:
>> I've been working on porting the Gimp lcms.c plug-in from using
>> LittleCMS version 1 to using LittleCMS version 2. This will make
>> possible high bit-depth ICC profile conversions.
>>
>> I'm not a super-experienced c-coder, nor have I ever worked with the
>> lcms engine before. So I'm learning as I go. So far I've:
>> (1)compiled the existing Gimp lcms plug-in,
>> (2)modified the existing plug-in to use lcms2.h and attempted to
>> compile it (knowing it would fail)
>> (3)tracked down all the errors and warnings that result from the
>> differences between LittleCMS version 1 and LittleCMS version 2
>>
>> My next steps will be to add a whole bunch of "print to screen"
>> commands to the current Gimp lcms.c plug-in so I can get a better
>> handle on the flow of the code, and then start rewriting (or perhaps
>> writing from scratch) the plug-in to use the LittleCMS v2 engine.
>>
>> If anyone is curious, I've documented what I've done so far:
>>
>> http://ninedegreesbelow.com/temp/gimp-lcms-1.html
>> http://ninedegreesbelow.com/temp/gimp-lcms-2.html
>>
>> Comments, input is more than welcome.
>>
>> I have a couple of big-picture questions:
>>
>> Will Gimp be using as its internal working space some variant of
>> Microsoft's scRGB? What about:
>>
>> Wikipedia: http://en.wikipedia.org/wiki/Scrgb
>> "scRGB is a wide color gamut RGB (Red Green Blue) color space created
>> by Microsoft and HP that uses the same color primaries and white/black
>> points as the sRGB color space but allows coordinates below zero and
>> greater than one. . . . the cost of maintaining compatibility with
>> sRGB is that approximately 80% of the scRGB color space consists of
>> imaginary colors."
>>
>> "Two encodings are defined for the individual primaries: a linear 16
>> bit per channel encoding and a nonlinear 12 bit per channel encoding.
>> . . The 16 bit scRGB(16) encoding is the linear RGB channels converted
>> by 8192 x + 4096. Compared to 8-bit sRGB this ranges from about 1/2
>> the color resolution near 0.0 to more than 10 times the color
>> resolution
>> near 1.0."
>>
>> That last sentence is a bit worrisome - losing resolution in the shadow
>> areas.
>>
>> It seems to me that you will always need ICC profiles, to convert an
>> image from whatever ICC color space profile it happens to be in, to
>> your internal working space, and from your internal working space to
>> the monitor profile, and from your internal working space back out to
>> whatever color space profile the person wants to use to upon exporting
>> to a non-xcf file. Yes? No?
>>
>> Elle
>>
>
>
>


-- 
http://ninedegreesbelow.com
Articles and tutorials on open source digital imaging and photography