Re: [Gimp-developer] Re: The way forward for Color Management
Hi,
yesterday I suggested the following struct:
struct GimpColorConfig
{
GObject parent_instance;
gboolean enabled;
gchar *monitor_profile;
gchar *working_profile;
gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent;
};
What we didn't talk about yet is whether the profiles are filenames
that specify what ICC color profile to load or whether they are
pointers to color profiles loaded into memory.
I suggest that we use filenames here and let the modules deal with
loading the profile. Is loading a profile using lcms an expensive task
or is the file just mmap'ed? If it turns out to be a problem we could
consider to add a color profile cache that is shared by all display
filters and color selectors. The profiles would be identified by their
filename so the struct that I suggested should be good enough.
For image-specific profiles, I suggest that we continue to do what
we've been doing so far and that's attaching the loaded profile to the
image using the icc-profile parasite.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: What we didn't talk about yet is whether the profiles are filenames that specify what ICC color profile to load or whether they are pointers to color profiles loaded into memory. I suggest that we use filenames here and let the modules deal with loading the profile. Is loading a profile using lcms an expensive task or is the file just mmap'ed? If it turns out to be a problem we could consider to add a color profile cache that is shared by all display filters and color selectors. The profiles would be identified by their filename so the struct that I suggested should be good enough. I'm in full agreement over passing filenames instead of blocks of memory. There's a bit more to opening a profile than a simple mmap() - there's a header that much be parsed, and endianness issues taken into account - but it's not that expensive. What is quite expensive is creating a transform from a pair of profiles, so if we could cache the transforms it would be worthwhile. The other possibility is to have a single instance of the display filter used across all images and the colour-selectors, and then allow an image parasite to disable it. Advanced users could then set up through the View-Display Filters dialog any custom transforms that they require. This would more or less guarantee that inexperienced users won't accidentally end up with mismatched color-spaces, while still providing enough flexibility for advanced users. For image-specific profiles, I suggest that we continue to do what we've been doing so far and that's attaching the loaded profile to the image using the icc-profile parasite. Agreed. Upon image load, if this parasite exists and the user wants to transform to the working space, then a plugin will transform from this binary profile to the working profile, after which this parasite can be flushed. If the user doesn't convert to the working profile, the parasite will remain, and will be available to the display filters if the user subsequently sets up a custom transform. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven,
Sven Neumann wrote:
yesterday I suggested the following struct:
struct GimpColorConfig
{
GObject parent_instance;
gboolean enabled;
gchar *monitor_profile;
gchar *working_profile;
gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent;
};
I've just realised that we haven't made any provision for LCMS's very
useful alarm-colour ability for soft-proofing - in short, it can be made
to replace any colours that can't be represented on the output device
(out-of-gamut colours) with an alarm colour. (Lime green and shocking
pink seem to be good choices!)
In order to support this feature, we'd need one more flag and an
appropriate RGB colour:
gboolean proof_use_alarm;
RGBTriple proof_alarm_color;
All the best,
--
Alastair M. Robinson
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: In order to support this feature, we'd need one more flag and an appropriate RGB colour: gboolean proof_use_alarm; RGBTriple proof_alarm_color; That would be a feature that is enabled per display and doesn't need to be stored globally ?! Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: In order to support this feature, we'd need one more flag and an appropriate RGB colour: gboolean proof_use_alarm; RGBTriple proof_alarm_color; That would be a feature that is enabled per display and doesn't need to be stored globally ?! Perhaps - though I can see some value in applying it to the colour selector, so you can see which colours are off limits when targeting a specific device. All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: You misunderstood me. What I was saying is that GIMP 2.0 has the API to implement all this and I would have loved to see this added about a year ago when it was proposed quite detailed already. Since that didn't happen we can now also do some useful changes to the modules API and to the core to integrate it even better. GimpDisplayConfig is OK - I've asked this before, but can anyone provide me with, or point me at, a transcript of the previous discussions? however definitely the wrong object to add this stuff to. I will try to write down my ideas on how to share color management configuration somewhen this weekend. OK - fair enough - I look forward to reading it :) Forgive my over-enthusiasm on this; I'm keen to see this get into 2.2, but no-one else has expressed an interest in coding this, and with a feature freeze approaching, I wanted at least a working prototype. (In fact, I'm already finding the modified proof filter useful, if tedious to set up every time an image is opened!) The proof filter should do proofs and nothing but proofs. What you are suggesting sounds more like a new filter. Again, that's understood - but I would recommend renaming the existing filter rather than having two separate ones; soft-proofing and normal colour management are not only almost identical code-wise, but mutually exclusive (at least as far as the display filters go). If you look at the code, you'll see that the bulk of it is in adding support for working and monitor profiles (both of which are necessary - at least until we've decided on the configuration issues - for the proof filter anyway). The only code that differs for the two modes is that normal color-management calls cmsCreateTransform() instead of cmsCreateProofingTransform(). All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi Sven, Sven Neumann wrote: it would help a lot if you could send some information on what settings you think are needed for color management. I know this info is in Bugzilla but I'd like to see it mentioned here so that we can start to discuss how to implement it in a way that it can be used from display filter modules. I guess we also need the same info to be accessible by plug-ins also? We will then also have to add a PDB API to access them (read-only ?). OK - in approximate order of importance: colour_management_enabled - speaks for itself. Must be accessible from the loading code, since a user who has disabled color-management won't want to be bothered by embedded-profile-related questions. monitor_profile - read access needed by the display filter. Write access available to plugins would make a rough-cut monitor profiling plugin possible. working_profile - characterises the GIMP internal working space. Will default to sRGB (and will probably stay that way for most users), but some poeple have expressed an interest in using AdobeRGB instead. Read access required by the yet-to-be-written colour-management plugin that will transform from an image's embedded profile to the working profile. proof_profile - this profile characterises a device to be simulated by the proofing mode. This will typically be a CMYK profile, and these can be large (USWebCoatedSWOP.icc is over half a megabyte), so it makes sense to try and avoid having a separate instance of this filter for every image. Should only be needed by the display filter. rendering_intent - This affects how littlecms will transform the colours. Needed by the display filter. proofing_intent - In proofing mode, rendering_intent specifies how colours are rendered on the simulated device. proofing_intent is needed to specify how this simulated data is rendered on the monitor. Again, needed by the display filter. That should pretty much cover it. I think it's important to be able to disable color-management for a specific image, and I would like to be able to override the working profile for specific images, (which means getting an image parameter into the display filter so parasites can be fetched). Hope this is some help :) All the best, -- Alastair M. Robinson ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Re: The way forward for Color Management
Hi,
Alastair M. Robinson [EMAIL PROTECTED] writes:
OK - in approximate order of importance:
colour_management_enabled - speaks for itself. Must be accessible
from the loading code, since a user who has disabled color-management
won't want to be bothered by embedded-profile-related questions.
monitor_profile - read access needed by the display filter. Write
access available to plugins would make a rough-cut monitor profiling
plugin possible.
working_profile - characterises the GIMP internal working space. Will
default to sRGB (and will probably stay that way for most users), but
some poeple have expressed an interest in using AdobeRGB instead.
Read access required by the yet-to-be-written colour-management plugin
that will transform from an image's embedded profile to the working
profile.
proof_profile - this profile characterises a device to be simulated by
the proofing mode. This will typically be a CMYK profile, and these
can be large (USWebCoatedSWOP.icc is over half a megabyte), so it
makes sense to try and avoid having a separate instance of this filter
for every image. Should only be needed by the display filter.
rendering_intent - This affects how littlecms will transform the
colours. Needed by the display filter.
proofing_intent - In proofing mode, rendering_intent specifies how
colours are rendered on the simulated device. proofing_intent is
needed to specify how this simulated data is rendered on the monitor.
Again, needed by the display filter.
OK, so we would need something like this:
enum GimpColorIntent
{
GIMP_COLOR_INTENT_PERCEPTUAL,
GIMP_COLOR_INTENT_RELATIVE_COLORIMETRIC,
GIMP_COLOR_INTENT_SATURATION,
GIMP_COLOR_INTENT_ABSOLUTE_COLORIMETRIC
};
struct GimpColorConfig
{
GObject parent_instance;
gboolean enabled;
gchar *monitor_profile;
gchar *working_profile;
gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent;
};
This object could live in libgimpcolor so that it can be used from the
core, modules and plug-ins. Of course plug-ins wouldn't see the real
core object, we need to define one or more PDB calls to communicate
these values. libgimpui can take care of hiding these PDB calls from
plug-ins so all they see is the object. It would make things easier if
only read access needs to be necessary for plug-ins. At least to begin
with, we can always add write access later.
The core instance of this object would implement the
GimpConfigInterface so that we can attach it to the gimprc object (or
even derive GimpBaseConfig from it). This little hack will take care
of storing these value in the gimprc file and it will make it trivial
to add widgets for these values to the preferences dialog.
We might have to change the GimpColorDisplay and GimpColorSelector
modules APIs but I am not reluctant to do that. I don't know of any
third-party modules that would be using it. We promised API and ABI
compatibility for plug-ins and I want to stick to that rule but I
think we can break the modules API in incompatible ways if we need to.
That should pretty much cover it. I think it's important to be able
to disable color-management for a specific image, and I would like
to be able to override the working profile for specific images,
(which means getting an image parameter into the display filter so
parasites can be fetched).
Yes, both display filter and color selector modules will have to get
access to GimpColorConfig. The display filters also need access to the
image's profile. The latter could be handled by letting the module
access the image parasites. By using a parasite for the image profile
this value is instantly available to plug-ins and will make it
possible to develop a plug-in that converts the image to a different
working space.
Sven
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: The way forward for Color Management
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: 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? You misunderstood me. What I was saying is that GIMP 2.0 has the API to implement all this and I would have loved to see this added about a year ago when it was proposed quite detailed already. Since that didn't happen we can now also do some useful changes to the modules API and to the core to integrate it even better. GimpDisplayConfig is however definitely the wrong object to add this stuff to. I will try to write down my ideas on how to share color management configuration somewhen this weekend. Time, perhaps, to open Bugzilla issues for these changes? I don't think so. It will only cause more work. Instead we should discuss here what changes we actually need. The actual implementation is the minor part. 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. The proof filter should do proofs and nothing but proofs. What you are suggesting sounds more like a new filter. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Re: The way forward for Color Management
Hi, it would help a lot if you could send some information on what settings you think are needed for color management. I know this info is in Bugzilla but I'd like to see it mentioned here so that we can start to discuss how to implement it in a way that it can be used from display filter modules. I guess we also need the same info to be accessible by plug-ins also? We will then also have to add a PDB API to access them (read-only ?). Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
