RSS/Atom feed Twitter
Site is read-only, email is disabled

The way forward for Color Management

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

22 of 22 messages available
Toggle history

Please log in to manage your subscriptions.

The way forward for Color Management Alastair M. Robinson 13 Aug 01:41
  The way forward for Color Management Øyvind Kolås 13 Aug 13:29
   The way forward for Color Management Alastair M. Robinson 13 Aug 14:48
  The way forward for Color Management Nathan Carl Summers 13 Aug 16:35
   The way forward for Color Management Alastair M. Robinson 13 Aug 20:24
  The way forward for Color Management Sven Neumann 14 Aug 01:39
   The way forward for Color Management Alastair M. Robinson 14 Aug 14:46
  The way forward for Color Management Sven Neumann 14 Aug 02:08
   CMS PDBs in CinePaint/GIMP Kai-Uwe Behrmann 14 Aug 16:33
    CMS PDBs in CinePaint/GIMP Sven Neumann 14 Aug 18:16
     CMS PDBs in CinePaint/GIMP Kai-Uwe Behrmann 15 Aug 00:09
      CMS PDBs in CinePaint/GIMP Sven Neumann 15 Aug 00:21
       CMS PDBs in CinePaint/GIMP Kai-Uwe Behrmann 15 Aug 09:52
        CMS PDBs in CinePaint/GIMP Sven Neumann 15 Aug 11:15
         CMS PDBs in CinePaint/GIMP Alastair M. Robinson 15 Aug 13:09
   The way forward for Color Management Alastair M. Robinson 15 Aug 00:40
    The way forward for Color Management Sven Neumann 15 Aug 01:50
     The way forward for Color Management Sven Neumann 15 Aug 11:38
      The way forward for Color Management Alastair M. Robinson 15 Aug 13:26
      The way forward for Color Management Alastair M. Robinson 15 Aug 17:32
       The way forward for Color Management Sven Neumann 15 Aug 20:35
        The way forward for Color Management Alastair M. Robinson 16 Aug 00:53
Alastair M. Robinson
2004-08-13 01:41:50 UTC (over 19 years ago)

The way forward for Color Management

Hi Sven,

> 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

Øyvind Kolås
2004-08-13 13:29:32 UTC (over 19 years ago)

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

Alastair M. Robinson
2004-08-13 14:48:13 UTC (over 19 years ago)

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

Nathan Carl Summers
2004-08-13 16:35:56 UTC (over 19 years ago)

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

Alastair M. Robinson
2004-08-13 20:24:19 UTC (over 19 years ago)

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

Sven Neumann
2004-08-14 01:39:58 UTC (over 19 years ago)

The way forward for Color Management

Hi,

"Alastair M. Robinson" 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

Sven Neumann
2004-08-14 02:08:09 UTC (over 19 years ago)

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

Alastair M. Robinson
2004-08-14 14:46:19 UTC (over 19 years ago)

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

Kai-Uwe Behrmann
2004-08-14 16:33:33 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hi,

Are You interessted into sharing the same PDB function names from what is allready gone into CinePaint?

This kind of integration would help writers of future plug-ins to port to and from GIMP.
Please let me know and I will go and post the related things here. You can then decide by as You like.

regards Kai-Uwe Behrmann
+ imaging development / panoramas + color management + email :ku.b@gmx.de

PS: ICC conversion to CMYK is done in my version of the print plug-in not in the tiff plug-in

Am 14.08.04, 02:08 +0200 schrieb Sven Neumann:

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

Sven Neumann
2004-08-14 18:16:40 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hi,

Kai-Uwe Behrmann writes:

Are You interessted into sharing the same PDB function names from what is allready gone into CinePaint?

You aren't still using or even still adding PDB names that use the GIMP namespace to CinePaint or are you?

Sven

Kai-Uwe Behrmann
2004-08-15 00:09:22 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

As long as there is somthing simple possible like:

#define cinepaint_func gimp-func

#namespace_GIMP gimp_func (whatever_You_like, arguments); #endif
#namespace_CinePaint
cinepaint_func (whatever_You_like, arguments); #endif

possible, I think all is fine. But starting of something like:

/* one design in GIMP: */ gimp_func (opts_float_array[3], "string"); /* and for the same in cinepaint: */ cinepaint_func (integer_A, integer_B, enum SELECT_STRING, double_C);

Most important is IMHO to take the same arguments and stay in the sense of an function name (as most as possible) common.

Do You have any concerns using gimp_func(....) in CinePaint?

regards Kai-Uwe

Am 14.08.04, 18:16 +0200 schrieb Sven Neumann:

Hi,

Kai-Uwe Behrmann writes:

Are You interessted into sharing the same PDB function names from what is allready gone into CinePaint?

You aren't still using or even still adding PDB names that use the GIMP namespace to CinePaint or are you?

Sven

Sven Neumann
2004-08-15 00:21:35 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hi,

Kai-Uwe Behrmann writes:

As long as there is somthing simple possible like:

#define cinepaint_func gimp-func

#namespace_GIMP gimp_func (whatever_You_like, arguments); #endif
#namespace_CinePaint
cinepaint_func (whatever_You_like, arguments); #endif

possible, I think all is fine.

I wouldn't call such a mess fine. But if you think so...

The real question here is if the API is sane, fits our needs and goes well with the rest of the GIMP API. So if you want to suggest that we consider something similar to the CinePaint API, you should show us that API.

Do You have any concerns using gimp_func(....) in CinePaint?

Yes indeed and I have expressed these concerns in the past. The GIMP namespace and the GIMP fileformats are reserved for use by the GIMP project and shouldn't be abused by other apps. Do I really need to explain the purpose of namespaces?

Sven

Alastair M. Robinson
2004-08-15 00:40:02 UTC (over 19 years ago)

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

Sven Neumann
2004-08-15 01:50:38 UTC (over 19 years ago)

The way forward for Color Management

Hi,

"Alastair M. Robinson" 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

Kai-Uwe Behrmann
2004-08-15 09:52:20 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hello,

Here comes what I have put in CinePaints standard plugin header :

void gimp_image_set_icc_profile_by_name (gint32 image_ID, gchar *data); void gimp_image_set_icc_profile_by_mem (gint32 image_ID, gint size, gchar *data); void gimp_image_set_lab_profile (gint32 image_ID); void gimp_image_set_xyz_profile (gint32 image_ID); void gimp_image_set_srgb_profile (gint32 image_ID); gboolean gimp_image_has_icc_profile (gint32 image_ID); char* gimp_image_get_icc_profile_by_mem (gint32 image_ID, gint *size); char* gimp_image_get_icc_profile_info (gint32 image_ID); char* gimp_image_get_icc_profile_pcs (gint32 image_ID); char* gimp_image_get_icc_profile_color_space_name (gint32 image_ID); char* gimp_image_get_icc_profile_device_class_name (gint32 image_ID);

gint32 gimp_display_get_cms_intent (gint32 display_ID); void gimp_display_set_cms_intent (gint32 display_ID, gint32 intent); gint32 gimp_display_get_cms_flags (gint32 display_ID); void gimp_display_set_cms_flags (gint32 display_ID, gint32 flags); gint32 gimp_display_is_colormanaged (gint32 display_ID); void gimp_display_set_colormanaged (gint32 display_ID, gboolean True_False); void gimp_display_all_set_colormanaged (gboolean True_False); void gimp_display_image_set_colormanaged(gint32 display_ID, gboolean True_False);

flags and intents are identical to lcms.h and at least flags are specific to lcms. About proofing: as CinePaints print plug-in shows the separated CMYK image as an softproof on output, there is currently no function for proofing in the API.

The namespace macro below was intended to show different examples. The real life part would be the first define. Ifdefs are not! needed related to an color management API.

I expect a lot of ICC handling plug-ins, once CMS is established in more applications :)

regards
Kai-Uwe

Am 15.08.04, 00:21 +0200 schrieb Sven Neumann:

Hi,

Kai-Uwe Behrmann writes:

As long as there is somthing simple possible like:

#define cinepaint_func gimp-func

#namespace_GIMP gimp_func (whatever_You_like, arguments); #endif
#namespace_CinePaint
cinepaint_func (whatever_You_like, arguments); #endif

possible, I think all is fine.

I wouldn't call such a mess fine. But if you think so...

The real question here is if the API is sane, fits our needs and goes well with the rest of the GIMP API. So if you want to suggest that we consider something similar to the CinePaint API, you should show us that API.

Do You have any concerns using gimp_func(....) in CinePaint?

Yes indeed and I have expressed these concerns in the past. The GIMP namespace and the GIMP fileformats are reserved for use by the GIMP project and shouldn't be abused by other apps. Do I really need to explain the purpose of namespaces?

Sven

Sven Neumann
2004-08-15 11:15:31 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hi,

Kai-Uwe Behrmann writes:

Here comes what I have put in CinePaints standard plugin header :

void gimp_image_set_icc_profile_by_name (gint32 image_ID, gchar *data);

"data" is a filename ?

void gimp_image_set_lab_profile (gint32 image_ID); void gimp_image_set_xyz_profile (gint32 image_ID); void gimp_image_set_srgb_profile (gint32 image_ID);

What are these? Setters without a value?

char* gimp_image_get_icc_profile_info (gint32 image_ID); char* gimp_image_get_icc_profile_pcs (gint32 image_ID); char* gimp_image_get_icc_profile_color_space_name (gint32 image_ID); char* gimp_image_get_icc_profile_device_class_name (gint32 image_ID);

Why are these functions part of the GimpImage API? They work on the color profile, don't they? It should be sufficient to get access to the profile, then use lcms API to retrieve that information.

gint32 gimp_display_get_cms_intent (gint32 display_ID); void gimp_display_set_cms_intent (gint32 display_ID, gint32 intent); gint32 gimp_display_get_cms_flags (gint32 display_ID); void gimp_display_set_cms_flags (gint32 display_ID, gint32 flags); gint32 gimp_display_is_colormanaged (gint32 display_ID); void gimp_display_set_colormanaged (gint32 display_ID, gboolean True_False); void gimp_display_all_set_colormanaged (gboolean True_False); void gimp_display_image_set_colormanaged(gint32 display_ID, gboolean True_False);

I don't think it makes sense to expose CMS on the display level to plug-ins. We will handle this with modules and modules don't use the PDB.

Sven

Sven Neumann
2004-08-15 11:38:38 UTC (over 19 years ago)

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

Alastair M. Robinson
2004-08-15 13:09:07 UTC (over 19 years ago)

CMS PDBs in CinePaint/GIMP

Hi Sven,

Sven Neumann wrote:

Kai-Uwe Behrmann writes:

void gimp_image_set_lab_profile (gint32 image_ID); void gimp_image_set_xyz_profile (gint32 image_ID); void gimp_image_set_srgb_profile (gint32 image_ID);

What are these? Setters without a value?

Yes, LittleCMS has a few "standard" built-in profiles that can be used without a file on disk. sRGB is the only one we need; rather than expose it at the API level, we could just use it as a default if an empty or NULL string is passed where we expect a filename.

All the best, --
Alastair M. Robinson

Alastair M. Robinson
2004-08-15 13:26:21 UTC (over 19 years ago)

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

Alastair M. Robinson
2004-08-15 17:32:29 UTC (over 19 years ago)

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

Sven Neumann
2004-08-15 20:35:57 UTC (over 19 years ago)

The way forward for Color Management

Hi,

"Alastair M. Robinson" 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

Alastair M. Robinson
2004-08-16 00:53:02 UTC (over 19 years ago)

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