Hi Everyone,

Sven Neumann wrote:

Color management

This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks.

Here's a first attempt at a suitable specification:

Colour management will bring two major benefits to The GIMP: 1.Accurate display of colours when equipped with a suitable monitor profile. 2.The ability to perform a soft-proof, whereby an image is rendered to simulate how it will look on a particular output device (usually a printing press).

Implementation: The hard work is performed by LittleCMS, while the existing proof display filter can provide both of these facilities with a little modification; most of the details remaining to be finalised are interface and infrastructure related.

I can provide an outline here of what needs to be done; someone with a more in-depth knowledge of GIMP’s internals will have to tell us how much work this will entail:

(The following assumes that we’re going to create some kind of global display filter for colour-matching, rather than (or as well as) the current per-image ones – at the very least, such a filter will be needed for colour-correcting the colour-selectors...)

* Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.)
* GimpFileEntry for working space profile (ie the source profile provided to lcms)
* GimpFileEntry for monitor profile (the destination profile for lcms) * GimpFileEntry for proof profile (the profile of the device to be simulated, e.g. USWebCoatedSWOP.

Implementation details: lcms has a built-in sRGB profile, which should be used as a default if the working space or monitor profile entries are left blank.
If the proof profile is left blank, then the display filter will use a normal transform instead of a proofing transform. If all three are left blank, then the display filter should be disabled, since it won’t have any work to do!

* Update the proof display filter to allow straight Working Space -> Monitor Profile transforms as well as full proofing transforms. This is a trivial modification, and I have it working here. The filter (at least the global one) needs to be able to fetch the profiles from wherever the prefs dialog stores them. If the display filter becomes able to fetch parasites from the image, then it becomes possible (easy) to disable colour management on a per-image basis, and perform other tricks like overriding the working space for the separate plugin’s fake composite CMYK images.

That’s it as far as displaying accurate colour goes, and even if we get no further than this for 2.2, it’s a worthwhile start.

The next step will be to write a plugin for converting between colour spaces. This is not a difficult task. A couple of questions: * Do we allow the user to convert between arbitrary profiles, or only allow the current working space as a destination? * Where in the menu structure should this live?

Finally, the image loading code needs to modified. Any loaders for formats that support embedded ICC profiles should attach it (as binary) to the image as a parasite named “icc-profile”. The loading code will check for this parasite on the loading of an image, and allow the user to choose between converting to the working space or disabling colour-management for this image.

A special case will be the TIFF plugin – TIFFs can contain embedded profiles for a CMYK colour space; ideally the TIFF plugin itself will use lcms to convert the raw CMYK data to the RGB Working Space.

I think this covers most of what’s needed to make colour management a useful addition to The GIMP.

Comments please, both on difficulty of implementation and any technical points that need to be discussed further.

All the best, --
Alastair M. Robinson

From: Sven Neumann
Date: 09 Aug 2004 00:10:48 +0200

I think it's about time to start to discuss what features we still want to get into GIMP 2.2. We are targetting a feature freeze by the end of the month and a release shortly after, so it's probably about time...

I'd like to collect a list of changes what we want to see being done for 2.2. We will need people to pick up these tasks and finish them in the next weeks. I will make a start by listing some of the things that I think would be great to finish for 2.2. Please add your wishes and/or take responsibility for some of these tasks. If you want to go into detail about a task that is listed below, please create a new thread for it so we can use this thread for collecting ideas.

Gimp-Print 5.0 isn't going to be in final release at that point, but it should be at beta-2 by then, and we've been putting a lot of bug fixes into our tree. I don't think it's as stable as 4.2 yet, but it's not far shy. We should be completely API-frozen at that point. We need to work out handoff of the plugin, as discussed.

The only API change we're looking at right now is adding dimension-valued parameters. These are like numerical parameters, except that programs should present them in the appropriate units, such as inches, mm, points, furlongs, or whatnot. The short-term reason for this is to allow precise registration of CD's. We could either make the change and then hand it off, or we could hand it off and you could make the change. Since the only real implication of this is for the UI, and it sounds like you're going to overhaul the UI, perhaps we should hand it off first.

I'll be away this week, so don't expect any replies from me until next Sunday or so.

Color management

This has been discussed quite thoroughly but it still needs to be written down in some sort of specification and then been cut down into tasks.

Please copy gimp-print-devel@lists.sourceforge.net on appropriate discussion on this topic.

* Add a new section in the preferences dialog (or add to the existing Display section) the following options: * Enable/disable colour management (Do we allow this to be enabled/disabled on a per-image basis? The filter will need access to image parasites for that.)

I can't honestly think of a good reason to disable color management, but couldn't we just have an option for "this monitor's colorspace" instead of having two choice to choose from?

On second thought, I can think of a reason to disable color management, but I still think that it wouldn't be a bad idea to just make "this monitor's colorspace" one of the options.

Rockwalrus

Sven Neumann wrote:

I think it's about time to start to discuss what features we still want to get into GIMP 2.2.

Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that?

Am 10.09.04, 00:41 +0100 schrieb Alastair M. Robinson:

...

A special case will be the TIFF plugin ? TIFFs can contain embedded profiles for a CMYK colour space; ideally the TIFF plugin itself will use lcms to convert the raw CMYK data to the RGB Working Space.

I had this code inside the tiff reader, but stripped it out now, because CinePaints internal color management can handle CMYK natively. Anyway if You like to look into the old tiff code, let me know and I will send it to anyone interessted.

kind regards

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

From: Sven Neumann
Date: 09 Aug 2004 11:15:38 +0200

Robert L Krawitz writes:

> The only API change we're looking at right now is adding > dimension-valued parameters. These are like numerical > parameters, except that programs should present them in the > appropriate units, such as inches, mm, points, furlongs, or > whatnot. The short-term reason for this is to allow precise > registration of CD's. We could either make the change and then > hand it off, or we could hand it off and you could make the > change. Since the only real implication of this is for the UI, > and it sounds like you're going to overhaul the UI, perhaps we > should hand it off first.

GIMP has all this already, why would you want to deal with units in a library such as gimp-print?

Two reasons:

1) Gimp-Print covers more than just the GIMP -- there's also the CUPS driver, the Ghostscript IJS driver, and Foomatic, in addition to a few third party apps.

2) The dimension type tells the user interface to treat this parameter specially (display it in units of the user's choice).

Sven,

Something that I'd like to see (if it hasn't been done yet) is to make the popup progress dialog dockable. How feasible is that?

Well, we don't want to make it dockable, it should be embedded in the associated dialog. Yes, that should definitely be on the list for 2.2.

What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window.

Hi,

Nathan Carl Summers wrote:

I can't honestly think of a good reason to disable color management, but couldn't we just have an option for "this monitor's colorspace" instead of having two choice to choose from?

Colour management is in two distinct parts - display and loading/saving. The option I'm talking about here would simply turn off the display filter, which will increase redraw speed, and perhaps save a little memory.

I'm not sure I quite understand your other point - are you saying we should forget about having a "working space" and just use the monitor's colour space directly? I can see some appeal to the simplicity of this idea. Pros and cons I can think of are:

Pros: * The need for a display filter is eliminated (except for soft-proofing)

Cons: * Images saved in non-CMS aware formats (BMP, PCX, JPG) will be assumed by CMS aware software to be in sRGB - which would look awful for images that are in fact in the colour space of, for example, my laptop's screen!

* The effect of certain plugins will be unpredictable. One of the goals of colour management is that things like GFlare or other plugins that render graphics will be consistent across hardware if we use a standardised working space. We lose this advantage if we don't use a working space.

* Images have to be converted into the Monitor's colour space on loading, which means a destructive change to the data. If I'm working on images I've scanned, I'll want to set the working space to the profile of my scanner (even if I have to go to the preferences to do it, I'll do this rather than convert the data to sRGB or the monitor's colour space).

I think the cons of this approach outweight the pros, but working this way would be possible if one were to disable the display filter, and set the working space to the monitor's profile.

All the best, --
Alastair M. Robinson

Nathan Carl Summers wrote:

I can't honestly think of a good reason to disable color management, but couldn't we just have an option for "this monitor's colorspace" instead of having two choice to choose from?

The first time I tried to use PhotoShop with color management, I was totally bewildered: it was asking me all these questions about color conversions, and I had no idea what they meant or how to answer them. A significant part of my bad attitude toward PhotoShop comes from that experience.

I think it is important for new users to be able to make color management *just go away* until they know what it means and are ready to deal with it. Gimp is a hard enough program to learn as it is.

Best,
-- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

On Mon, Aug 09, 2004 at 09:29:46AM -0700, William Skaggs wrote:

Nathan Carl Summers wrote:

I can't honestly think of a good reason to disable color management, but couldn't we just have an option for "this monitor's colorspace" instead of having two choice to choose from?

The first time I tried to use PhotoShop with color management, I was totally bewildered: it was asking me all these questions about color conversions, and I had no idea what they meant or how to answer them. A significant part of my bad attitude toward PhotoShop comes from that experience.

I think it is important for new users to be able to make color management *just go away* until they know what it means and are ready to deal with it. Gimp is a hard enough program to learn as it is.

and then there are those of us who simply do not believe in it. i actually believe more in Santa Claus than i do in anyones ability to make a monitor match a print.

carol

I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars.

-Joseph

Sven Neumann wrote:

Hi,

David Hodson writes:

What if there's no associated dialog? I have some plugins that call (lots of) Gimp functions non-interactively, with no image display. The result is that the progress dialog is constantly being created and destroyed. Things would be much neater if it was (optionally?) just part of the main toolbox window.

The progress bar should then be part of the plug-in dialog that calls these functions. I don't think having the progress in the toolbox window is a good idea.

Sven

Joseph Heled wrote:

I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars.

You would argue incorrectly, then. Even if a plugin is noninteractive, bad things usually happen if you alter the image it is working on before it is finished. Therefore, you need to know whether the plugin is running, and it is nice to get some sense of how much longer it is going to take.

Best, -- Bill

______________ ______________ ______________ ______________ Sent via the KillerWebMail system at primate.ucdavis.edu

Hi,

Sven Neumann wrote:

No, that would be wrong. Non-interactive means that there's no user interaction, it doesn't mean that there's absolutely no feedback such as a progress bar. Some plug-ins used to behave the way you argue and we have hopefully found and changed them all to do the right thing which is to always indicate progress.

How does gimp-console handle plug-ins then? I assume it doesn't bring up progress curses windows...

Dave.

Hi,

Sven Neumann wrote:

one or two things for GIMP 2.2 that I forgot:

Script-Fu vs. Tiny-Fu

We should come to a conclusion whether and how Tiny-Fu can replace Script-Fu. I'd suggest we make separate packages gimp-script-fu and gimp-tiny-fu and remove Script-Fu from the gimp tree.

I think we could include both in the standard distribution, making tiny-fu the default and having script-fu as a fall-back. Despite all the testing it has had so far, it's inevitable that tiny-fu will have some teething problems when it gains very wide exposure in a stable GIMP.

Python bindings

IMO we should move pygimp out of the gimp tree into a gimp-python package. That would make it easier to give it a proper python-like build environment and would make it easier for packagers. Yosh also had some great plans on improving pygimp. Would probably be a good idea to make these improvements independent of the GIMP release cycles.

Given that this has happened for gimp-perl already, I can see the logic in that.

Who is maintaining gimp-python right now, by the way? yosh?

Cheers, Dave.

Sven Neumann wrote:

The progress bar should then be part of the plug-in dialog that calls these functions.

OK, of course, should have seen that. Gotcha. (I'm sick today, so my brain isn't working properly.)

Joseph Heled wrote:

I would argue that non interactive plugins (or interactive plugin run in non interactive mode, which I presume to be the same thing), should not bring up any progress bars.

In my case, I have a batch processing plugin that sets up a sequence of operations interactively, then performs them on a collection of images. So my plugin UI is available to display the progress from each operation, as long as I can grab the progress callbacks from the gimp functions that I'm calling.

From: Sven Neumann
Date: 09 Aug 2004 12:53:25 +0200

Hi,

Robert L Krawitz writes:

> GIMP has all this already, why would you want to deal with units in > a library such as gimp-print? >
> Two reasons:
>
> 1) Gimp-Print covers more than just the GIMP -- there's also the CUPS > driver, the Ghostscript IJS driver, and Foomatic, in addition to a > few third party apps.

I suggest to leave it up to the application that uses gimp-print then. Any application that uses units in it's user interface will have a framework to deal with units. If you add your own framework to gimp-print you are only making things more complex.

Right. The problem is how the application determines whether a particular parameter is a measurement or just an arbitrary floating point number. The only piece of framework that Gimp-Print's going to have is a new parameter type that's a "unit" rather than a dimensionless floating point or integer number. How the application deals with that is up to it. Basically it sounds like we're in reasonable agreement here.

> 2) The dimension type tells the user interface to treat this > parameter specially (display it in units of the user's choice).

Any length parameter in GIMP is measured in pixels and if there's resolution information, the user is given the opportunity to use arbitrary units to specify it. The underlying code still sees nothing but pixels. I don't see why the underlying code (in this case gimp-print) would have to know about this.

That's an issue for the plugin to deal with. Gimp-Print deals entirely in points (1/72"), and it's up to the application to translate that into units useful for people.

In the future we may extend Gimp-Print to allow other fundamental units of measure, because 1/72" may not be fine enough. This can be done compatibly (make the default be 1/72", and provide a way for an application to specify a different base unit). But that's neither here nor there right now.

From: Sven Neumann
Date: 15 Aug 2004 02:39:20 +0200

Robert L Krawitz writes:

> Right. The problem is how the application determines whether a > particular parameter is a measurement or just an arbitrary floating > point number. The only piece of framework that Gimp-Print's going to > have is a new parameter type that's a "unit" rather than a > dimensionless floating point or integer number. How the application > deals with that is up to it. Basically it sounds like we're in > reasonable agreement here.

Yes, sounds like it. Perhaps it would be easier to speak in terms of code snippets...

From the libgimpprint standpoint, it's simply a matter of adding

STP_PARAMETER_TYPE_DIMENSION, along with the appropriate bounds and defaults members to stp_parameter_t.

typedef enum {
STP_PARAMETER_TYPE_STRING_LIST, /*!< Single string choice from a list. */ STP_PARAMETER_TYPE_INT, /*!< Integer. */ STP_PARAMETER_TYPE_BOOLEAN, /*!< Boolean. */ STP_PARAMETER_TYPE_DOUBLE, /*!< Floating point number. */ STP_PARAMETER_TYPE_CURVE, /*!< Curve. */ STP_PARAMETER_TYPE_FILE, /*!< Filename (NYI, need to consider security). */ STP_PARAMETER_TYPE_RAW, /*!< Raw, opaque data. */ STP_PARAMETER_TYPE_ARRAY, /*!< Array. */ STP_PARAMETER_TYPE_DIMENSION, /*!< Linear dimension. */ STP_PARAMETER_TYPE_INVALID /*!< Invalid type (should never be used). */ } stp_parameter_type_t;

> That's an issue for the plugin to deal with. Gimp-Print deals > entirely in points (1/72"), and it's up to the application to > translate that into units useful for people.

That's fine. As long as there's a clearly specified value, we can deal with that.

Fine.

On Friday 01 October 2004 10:46, Sven Neumann wrote:

Python bindings

IMO we should move pygimp out of the gimp tree into a gimp-python package. That would make it easier to give it a proper python-like build environment and would make it easier for packagers. Yosh also had some great plans on improving pygimp. Would probably be a good idea to make these improvements independent of the GIMP release cycles.

I didn't get any response whatsoever regarding Python. Makes me wonder if pygimp is still being maintained at all. I would really like to see a separate pygimp package. Can we please get this done for 2.2?

I've talked to Yosh about this, and he said he intend to do the move - but he seems to be quite busy lately. Jamesh also told he could not pick it alone.

I had been using it, but never had seen the code until this week - I am willing to help improve and maintaining it, but I lack the time and expertize needed to maintain a separte package all by myself.

Over the next week, I plan at least to clean up the tabs on the remianing python files. The widgtes should be mostly "rewidgetziled", since it is currntly using String Entries for almost everything. If it cannot be taken apart for 2.2, that at least could be done.

I would agree with the schdules on the other itens. If there is a delay, maybe text-transofrms could get in, but they'd need PDB-entries as well.

Another thing IMHO is important, although marked as low priority in bugzilla is exposing the full options for the transform tools in the PDB - BUG 137053
( http://bugzilla.gnome.org/show_bug.cgi?id=137053 ) That would make whole classes of plug-ins easier to write.

Sven