Re: [Gimp-developer] The way forward for Color Management
On Fri, 13 Aug 2004 00:41:50 +0100, Alastair M. Robinson From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module. This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument. Would it make sense to break down the processing chain of the modules in two parts? One part that is attached to the image, and one that is attached to the display projection - image filter - display filter - frame buffer the properties controlling the image filter could derive it's information from information available in parasites attached to the image, while the display filter would only use global settings set in the preferences. /Øyvind K ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The way forward for Color Management
Hi
Øyvind Kolås wrote:
Would it make sense to break down the processing chain of the modules in
two parts? One part that is attached to the image, and one that is
attached to the
display
projection - image filter - display filter - frame buffer
It's a possibility, but I think it's probably making things
unnecessarily complicated. Since we presumably want to avoid having two
sets of filter modules to maintain, the display filter would have to be
a special case of the image filter (or vice versa)?
I also think that for maximum flexibility, if we have a single global
color-management filter outside the image filter chain, we need to be
able to disable it if a color-management image filter is enabled. And
we still need to get an image parameter into the filter modules :)
A proof-of-concept image filter (based on the existing proof module) is
now attached as a patch to bug #78265. Configuration is currently done
through View-Display Filters - it needs to be made persistent, and
parasites are looking like the best way to do it.
I envisage it working something like this:
Fetch working profile from global parasites.
Fetch monitor profile from global parasites.
Fetch proof profile from global parasites.
if(we have an image)
{
if(we have an override-working-profile image parasite)
Fetch overridden working profile from image
if(we have an override-proof-profile image parasite)
Fetch overridden proof profile from image
}
This IMHO avoids too much unnecessary complication while providing the
flexibility I'd need to use it at work: I'd want to scan an image, and
rather than convert the image to sRGB, just tag it with the scanner's
profile, and have the display filter use that as the source profile.
This method also allows for proofing transforms to be enabled on
specific images.
As always, comments, criticisms and suggestions welcome :)
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The way forward for Color Management
On Fri, 13 Aug 2004, Alastair M. Robinson wrote: From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module. This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument. Wait -- the color selectors need to be filtered on a per-image basis as well. What if you are working in very different colorspaces for two images? It does you no good to select a color in the gamut of one image if you really wanted to select for the other one -- that color might not even be in the gamut of the the other image! Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] The way forward for Color Management
Hi Nathan, Nathan Carl Summers wrote: Wait -- the color selectors need to be filtered on a per-image basis as well. What if you are working in very different colorspaces for two images? It does you no good to select a color in the gamut of one image if you really wanted to select for the other one -- that color might not even be in the gamut of the the other image! You're quite right, but it's not possible at the moment to associate the colour selector with a given image; this was one of the chief arguments in favour of a fixed working space. I envisage the vast majority of work being done in the GIMP's working space, but for advanced uses, I think the ability to override this working space is important. The plugin / dialog or whatever is used to do this will have to include warnings about the color selector not matching the image if its colorspace is overridden. Personally I envisage needing the ability to override the working profile for two things: Firstly, tagging a scanned image with the scanner's profile. If the scanned image is a photograph, then the colour selector isn't likely to be used anyway - my photo editing usually involves layer-colors-curves, and the clone tool. If the user needs to pick a colour, he/she can always use the eye-dropper to grab one that's already in the image. If the scanned image is a logo or similar, then converting to sRGB is no hardship anyway, so the problem can be bypassed. The second reason I want to be able to override the working space is that the fake CMYK colour mode of my separate plugin uses a layer in darken only mode to do naive R=1-C type CMYK-RGB conversion, which gives over-saturated colours; with the aid of a custom profile, this can be much improved. While the issues with having a fixed profile for the colour selector are real, I think it's acceptable as long as inexperienced users aren't confronted with it. Only advanced users are likely to want this feature, and they can be expected to be savvy enough to understand the implications and work around them. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] The way forward for Color Management
Hi Sven, quoted text pulled over from Bugzilla There is currently no way a plug-in or a display filter could access these values if they become part of gimprc. If we would make them parasites, that should work out of the box w/o any changes to the core. Since parasites can be accessed from plug-ins, the configuration should also be done in a plug-in. While I can see the logic in that from a technical standpoint, I can't help feeling that from a user-interface perspective configuration should be done in the prefs dialog. Is there any reason (apart from technical inelegance) why the gimpdisplayconfig code that would handle getting and setting these options couldn't take responsibility for maintaining some suitable parasites? That's what I was expecting to happen outside the core GIMP development based on the GIMP 2.0 API already. Of course we could decide to do it differently now that we have the chance to do changes to the core. We need some minor changes to the core - presumably we want to avoid anything too drastic! From my point of view, I think it's important to tweak the display module system so that the display modules can fetch parasites on a per-image basis (rather than just global ones) - this will let me implement the features I want in the display module. This conflicts slightly with the goal of applying a filter to the colour selectors - but this should be solved easily enough with a NULL argument. The other major core change will be setting up default display filters - it's currently extremely tedious enabling the filter manually for each and every image that's opened! Time, perhaps, to open Bugzilla issues for these changes? I'm about to attach a proof-of-concept patch in Bugzilla that expands the proof module to do regular source-monitor colour correction, with optional soft-proofs, instead of just soft-proofs limited to sRGB source and monitor. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
