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

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

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

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

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

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

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

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

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

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

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

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

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