Hi,

Quoting Sven Neumann :

I do think however that we
should give us a little bit more time and try to get the following done during the next weeks:

- add more plug-in previews - try to make the previews scale with the dialog - implement color management as was discussed earlier - fix unit handling and resize / scale dialogs - allow for better layer positioning / alignment - integrate the metadata editor that Raphael is working on - finish and fix whatever is unfinished or broken

I would suggest we attempt to get a 2.2 prerelease out by the end of this month or early in october. Given the fact that the tree is fairly stable, we should then be able to deliver 2.2.0 by the end of october.

Sounds good. I think that we will be in a good position to see in a couple of weeks time whether these features are going to be in 2.2 or not - if there haven't been any commits in a 2.1.5 release or whatever for color management, for example, it is probably best not to wait for it. A pre-release in a month or so sounds good.

Cheers,
Dave.

--
Dave Neary
Lyon, France

On Mon, Sep 06, 2004 at 05:52:20PM +0200, Sven Neumann wrote:

Hi,

a while ago we decided for a feature freeze for GIMP 2.2 that should have taken effect last week. I haven't enforced this feature freeze yet because there's been some good hacking going on recently and I think we definitely wanted to have these features in 2.2. With the 2.1.4 release, we've reached a point where the new stuff (GimpProgress, GimpPreview) seems to be rather well working so we could declare a feature freeze right now. I do think however that we should give us a little bit more time and try to get the following done during the next weeks:

- add more plug-in previews

I'm already on this. If someone wants to help, please contact me.

- try to make the previews scale with the dialog

Just to make it clear, this would just resize the preview widget, nothing to do with a zoom feature.

- implement color management as was discussed earlier - fix unit handling and resize / scale dialogs - allow for better layer positioning / alignment - integrate the metadata editor that Raphael is working on - finish and fix whatever is unfinished or broken

I would suggest we attempt to get a 2.2 prerelease out by the end of this month or early in october. Given the fact that the tree is fairly stable, we should then be able to deliver 2.2.0 by the end of october.

Sounds reasonable.

DindinX

From: Sven Neumann
Date: 06 Sep 2004 17:52:20 +0200

a while ago we decided for a feature freeze for GIMP 2.2 that should have taken effect last week. I haven't enforced this feature freeze yet because there's been some good hacking going on recently and I think we definitely wanted to have these features in 2.2. With the 2.1.4 release, we've reached a point where the new stuff (GimpProgress, GimpPreview) seems to be rather well working so we could declare a feature freeze right now. I do think however that we should give us a little bit more time and try to get the following done during the next weeks:

- add more plug-in previews - try to make the previews scale with the dialog - implement color management as was discussed earlier - fix unit handling and resize / scale dialogs - allow for better layer positioning / alignment - integrate the metadata editor that Raphael is working on - finish and fix whatever is unfinished or broken

I would suggest we attempt to get a 2.2 prerelease out by the end of this month or early in october. Given the fact that the tree is fairly stable, we should then be able to deliver 2.2.0 by the end of october.

Please comment on this proposal if you disagree with it or think there are important features missing that you are already working on.

I'd like to get a decision on what to do with the print plugin.

We (Gimp-Print) are in 5.0 beta, and I'd like for the GIMP 2.2 to use a 5.0-based plugin rather than a 4.2-based one. The Gimp-Print source tree has a GIMP 2.x-based plugin. There has been discussion about transferring ownership to the GIMP, and if this is going to happen it should be done soon. If it's going to stay in the Gimp-Print tree, it needs a maintainer, since the people who have been doing it aren't really GIMP experts nor UI programmers in general.

Particularly if there is to be color management in the GIMP, we need to look at this carefully. Doing 8 bit->8 bit color transformations prior to printing will yield quality problems that could be solved with 8 bit->16 bit transformations, as Gimp-Print can handle 16 bit input.

Sven wrote:

Please comment on this proposal if you disagree with it or think there are important features missing that you are already working on.

I don't disagree with it, but I wish you had mentioned specifically what I consider the biggest issue of all: bug #143668 (performance problems with GtkUIManager), which on a slow machine can make GIMP pause for 20 sec or more each time it creates an image. (Almost all this time is spent building the menus.) It would be a nightmare to release 2.2 without major improvement in this respect. The bug has been reassigned to Gtk+ rather than GIMP, but users aren't going to care.

Having spent some time on it myself, I think this bug is not going to be easy to solve, so it is disturbing that nobody is paying attention to it: the bug report has not even been commented on in over two months. If necessary I will take another shot at it myself, but I would prefer not to, for two reasons: first, I have been spending my time writing Help docs, and I believe it is possible to get the English part in good shape by the time 2.2 is released, but it will be much harder if I lose 1-2 weeks working on this bug; second, I don't really understand how the UI Manager works at all or how GIMP uses it.

Best, -- Bill

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

Hi Sven,

Sven Neumann wrote:

- implement color management as was discussed earlier

Firstly, I've been quiet on this subject for a few weeks because I've bought a new printer, and my limited coding time has been spent tweaking gimp-print to settle one or two minor print quality issues!

But to refresh everyone's memory about colour management, here is a list of what I believe needs to be done:

1. Create a new class for colour-management preferences, as you suggested:

struct GimpColorConfig {
GObject parent_instance;

gboolean enabled;

gchar *monitor_profile; gchar *working_profile; gchar *proof_profile;
GimpColorIntent render_intent;
GimpColorIntent proofing_intent; };

We need to be able to get this information into both the display filters and plugins. (Read only is probably sufficient for now.)

2. Modify the display filter interface to allow the current image to be referenced from within.

3. Allow the creation of a global display filter that will apply to all open images (unless disabled through an image parasite) and to the colour-selectors too. (For the latter, the image parameter passed to the module will be NULL)

4. Create a plugin that can transform an image between arbitrary RGB profiles. This plugin will need to be capable of using as source a binary profile attached to the image as a parasite "icc-profile", as applied by the TIFF loader. It will also need a user interface for interactive use.

5. When an image is newly loaded it should be checked for an icc-profile parasite, and if one is found the user should be given the *option* of converting the image to the current working space. If the user agrees, the parasite should be flushed after conversion, because the image will now be in the working space. If the user declines, a further parasite should be attached to the image that will disable colour-matching in the global display filter.

6. Image saving: some savers already support ICC profiles, as a binary parasite. We could simply load in the working profile and attach it as a parasite before saving, or we could do something smarter, providing the savers with access to the structure outlined in (1).

Does anyone have anything to add to this list, or can anyone see any fatal flaws or other problems that need to be resolved?

And the ultimate question: who's going to do what?

I can put some time into this, but probably not enough to do the entire list. Since I don't currently know GIMP's internals very well I think my time would best be spent working on the plugin mentioned in (4) and the display filters themselves, but points 1 and especially 2 need to be done first.

All the best,
--
Alastair M. Robinson

Date: Mon, 06 Sep 2004 23:21:49 +0100 From: "Alastair M. Robinson"

Sven Neumann wrote:

> - implement color management as was discussed earlier

Firstly, I've been quiet on this subject for a few weeks because I've bought a new printer, and my limited coding time has been spent tweaking gimp-print to settle one or two minor print quality issues!

Which we've very much appreciated, even though I still have to try out your latest. I've been busy with other things, like making dcraw do the right (IMHO) thing. But I digress.

But to refresh everyone's memory about colour management, here is a list of what I believe needs to be done: ...
Does anyone have anything to add to this list, or can anyone see any fatal flaws or other problems that need to be resolved?

It would *really* be helpful to plug this into the Print plugin, if not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the plugin these values are reprocessed into 16 bit values, rather than 8 bit ones.

Hi Robert,

Robert L Krawitz wrote:

Firstly, I've been quiet on this subject for a few weeks because I've bought a new printer, and my limited coding time has been spent tweaking gimp-print to settle one or two minor print quality issues!

Which we've very much appreciated, even though I still have to try out your latest. I've been busy with other things, like making dcraw do the right (IMHO) thing. But I digress.

Don't worry, I wasn't feeling unappreciated - just torn between two projects, like yourself :)

It would *really* be helpful to plug this into the Print plugin, if not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the plugin these values are reprocessed into 16 bit values, rather than 8 bit ones.

This should be a fairly trivial change once we have the infrastructure to get the current working profile and/or the image's profile into plugins in general.

The print plugin would itself need to link against lcms, and it would simply fetch the current working profile (or the image's own profile if there is one), and create a transform from 8-bit data in the source profile to 16-bit data in the destination profile.

The sticking point would be the destination profile - the user would need one that accurately describes gimp-print's characteristics! We could of course just use sRGB (which lcms has built-in) as a default.

All the best, --
Alastair M. Robinson

Date: Tue, 07 Sep 2004 19:34:41 +0100 From: "Alastair M. Robinson"

> It would *really* be helpful to plug this into the Print plugin, if > not Gimp-Print itself, so that when the GIMP feeds 8 bit values to the > plugin these values are reprocessed into 16 bit values, rather than 8 > bit ones.

This should be a fairly trivial change once we have the infrastructure to get the current working profile and/or the image's profile into plugins in general.

The print plugin would itself need to link against lcms, and it would simply fetch the current working profile (or the image's own profile if there is one), and create a transform from 8-bit data in the source profile to 16-bit data in the destination profile.

The sticking point would be the destination profile - the user would need one that accurately describes gimp-print's characteristics! We could of course just use sRGB (which lcms has built-in) as a default.

I'd really like to figure out the right thing for Gimp-Print to do here, and then apply the profile inside Gimp-Print.