Re: [Gimp-developer] Re: The way forward for Color Management

2004-08-15 Thread Sven Neumann
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

2004-08-15 Thread Alastair M. Robinson
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

2004-08-15 Thread Alastair M. Robinson
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

2004-08-15 Thread Sven Neumann
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

2004-08-15 Thread Alastair M. Robinson
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

2004-08-14 Thread Alastair M. Robinson
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

2004-08-14 Thread Alastair M. Robinson
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

2004-08-14 Thread Sven Neumann
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