Hi,
"Alastair M. Robinson" <blackfive@xxxxxxxxxxxxxxxxx> 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
