Hi,

"Joao S. O. Bueno" writes:

http://www.blackfiveservices.co.uk/separate.shtml

I am pointing people at this plug-in for quite a while already.

I hacked together a plugin some time ago that uses the LCMS colour-management library to convert images from RGB to CMYK, using ICC profiles.

Since the GIMP currently has no method of storing CMYK image data internally, I create a collection of layers, one for each channel, and use a custom save routine to create a CMYK TIFF from the layers.

I'd love to see the ability to convert to CMYK on save being added to the standard tiff plug-in. A naive CMYK conversion function is now in libgimpcolor but to make this really useful, the conversion should use color profiles, so this should probably be done using lcms.

It should be goal for GIMP-2.2 to add a framework for handling color profiles. Not only the TIFF plug-in would benefit from this. I know that work is being done on a display filter for color proofing. For this filter to be convenient and useful we will need a general way to select color profiles and to attach them to images. And we will have to improve the color display filter framework. This is working but there's quite some room for improvement here.

At the moment our TIFF plug-in already reads ICC profiles and attaches to the image using the "icc-profile" parasite (see devel-docs/parasites.txt). If I remember correctly it also writes the profile back to the TIFF file when saving. This parasite should be used by other plug-ins as well.

The CMYK color selector we have is also a module and be exchanged by an improved version that uses color profiles. So basically the infrastructure is there that enables some basic CMYK support to be added now without touching the GIMP core.

Someone or a group of people could try to come up with a CMYK extension package for GIMP-2.0. I imagine this as a package that contains a number of plug-ins replacing the standard file plug-ins for CMYK-aware formats, a CMYK color selector module and a number of color correction filters. If these plug-ins and modules all use lcms and share ICC profiles by means of gimprc and parasites, you could use GIMP to work on CMYK data even though it stores the data as RGB internally. This is of course limited CMYK support only but it would bring us a good way closer to it and I have been told that it should be sufficient for a lot of tasks,

There are however one or two changes needed to the current module API. Right now the modules have no way to access image parasites. Adding this would probably be small hack only. If someone comes up with such a patch quickly, perhaps we could even sneak it into 2.0 somehow.

Sven

Am 18.11.03, 22:49 +0100 schrieb Sven Neumann:

correction filters. If these plug-ins and modules all use lcms and share ICC profiles by means of gimprc and parasites, you could use

Have gimps configure an header check for lcms allready onboard? This would help plug-ins to easily link against liblcms?

Kai-Uwe

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Kai-Uwe Behrmann wrote: | Am 18.11.03, 22:49 +0100 schrieb Sven Neumann: |
|
|>correction filters. If these plug-ins and modules all use lcms and |>share ICC profiles by means of gimprc and parasites, you could use |
|
| Have gimps configure an header check for lcms allready onboard? This | would help plug-ins to easily link against liblcms?

I am working on an api for this in GEGL. It is probably best to use the system api's, when available, since there are already methods to plug lcms into the exisiting system api's (on windows and Mac OS X) as a CMM. ~ There will be an abstraction in GEGL for this. Eventually, I am going to try an get it moved to the freedesktop.org people (and into gtk). But that is quite a long term goal.

- -- Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/vZ5gad4P1+ZAZk0RAuVDAKCRS6p+8Vz2BbW3e6D7SxhMJ3iooACfWfvs IW22eyXeFgylASqfV5jWMQk=
=fe6n
-----END PGP SIGNATURE-----

Am 20.11.03, 21:10 -0800 schrieb Daniel Rogers:

I am working on an api for this in GEGL. It is probably best to use the system api's, when available, since there are already methods to plug lcms into the exisiting system api's (on windows and Mac OS X) as a CMM.

This would be fine for unix based systems too. Are there any plans to create an system interface for X to plug-in an CMM? Do You know someone allready working on this?

~ There will be an abstraction in GEGL for this. Eventually, I am going to try an get it moved to the freedesktop.org people (and into gtk). But that is quite a long term goal.

Can You provide more informations about the current state of CMS in GEGL?

regards Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

Have gimps configure an header check for lcms allready onboard? This would help plug-ins to easily link against liblcms?

I don't see how a configure check in GIMP would help plug-ins so the answer to the question doesn't really matter. I'll give it anway: I've added such a check a few minutes ago when the color proof display filter was added to CVS.

Sven

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Kai-Uwe Behrmann wrote: | Am 20.11.03, 21:10 -0800 schrieb Daniel Rogers: |
|
|>I am working on an api for this in GEGL. It is probably best to use the |>system api's, when available, since there are already methods to plug |>lcms into the exisiting system api's (on windows and Mac OS X) as a CMM. |
|
| This would be fine for unix based systems too. Are there any plans to | create an system interface for X to plug-in an CMM? | Do You know someone allready working on this?

yeah, I am working on this. Hopefully, I will be going to talk to the X.org and freedesktop people in December.

| |>~ There will be an abstraction in GEGL for this. Eventually, I am going |>to try an get it moved to the freedesktop.org people (and into gtk). |>But that is quite a long term goal. |
|
| Can You provide more informations about the current state of CMS in GEGL?

asking about the CMS in GEGL is really asking about the current state of LCMS. LCMS is a pretty darn complete color management system. And there isn't a lot of solid information. I know what I want to do, I just need to do it.

Ok, so I avoided the question. Do you want me to discuss technical details of how I think colormanagement will work in gegl?

- -- Daniel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/vjLYad4P1+ZAZk0RAlSoAJ99xIpYFjvU/SwLsoM7ycGYnFgksQCffwU/ PGXujXw8vKC9loidpL3+jVM=
=t8ym
-----END PGP SIGNATURE-----

Hi,

Kai-Uwe Behrmann writes:

This would be fine for unix based systems too. Are there any plans to create an system interface for X to plug-in an CMM? Do You know someone allready working on this?

X11 has support for color management for a loooong time already. What exactly is missing in your opinion?

Sven

web@tiscali.de (2003-11-21 at 0834.36 +0100):

This would be fine for unix based systems too. Are there any plans to create an system interface for X to plug-in an CMM? Do You know someone allready working on this?

apropos Xcms should give you some man pages, here it does. If one checks the background of X11 (ie, Silicon Graphics machines) it sounds logical to have such thing, I have heard that some people have used custom LUTs to do film work with plain Linux too... so it is all about lack of publicity and docs, I guess.

GSR

GSR - FR wrote:

web@tiscali.de (2003-11-21 at 0834.36 +0100):

This would be fine for unix based systems too. Are there any plans to create an system interface for X to plug-in an CMM? Do You know someone allready working on this?

apropos Xcms should give you some man pages, here it does. If one checks the background of X11 (ie, Silicon Graphics machines) it sounds logical to have such thing, I have heard that some people have used custom LUTs to do film work with plain Linux too... so it is all about lack of publicity and docs, I guess.

Ah, well I interpreted this slightly differently. While X11 does have color management support, it is not as good as lcms, and doesn't support the concept of CMM, which is what I really thought he was asking about. Pro people like to be able to buy Color Management Modules and plug them into the exsisting system apis.

-- Dan

... after the weekend
Am 21.11.03, 07:44 -0800 schrieb Daniel Rogers:

| This would be fine for unix based systems too. Are there any plans to | create an system interface for X to plug-in an CMM? | Do You know someone allready working on this?

yeah, I am working on this. Hopefully, I will be going to talk to the X.org and freedesktop people in December.

Staying interessted.

| Can You provide more informations about the current state of CMS in GEGL?

Ok, so I avoided the question. Do you want me to discuss technical details of how I think colormanagement will work in gegl?

Yes, I am interessted in how gegl handles color space conversions for instance. The more interessting question is how it is planed to get an interface for tools and plug-ins to handle the same command to all color spaces. For instance brighten an image affects all channels in RGB in Lab only the L (Lightness) channel.

By the way is gegl C++ and can it use templates to have only one function for all color depths in common? Sorry if I mix here something.

Maybe You like to continue the discussion in the gegl list, so I will need to subscribe.

regards
Kai-Uwe

Am 21.11.03, 09:37 -0800 schrieb Daniel Rogers:

Ah, well I interpreted this slightly differently. While X11 does have color management support, it is not as good as lcms, and doesn't support the concept of CMM, which is what I really thought he was asking about. Pro people like to be able to buy Color Management Modules and plug them into the exsisting system apis.

I heard lcms is plugable as an CMM module too (mac/win) and is sold for zero ;-)

--
Kai-Uwe

Am 21.11.03, 16:04 +0100 schrieb Sven Neumann:

would help plug-ins to easily link against liblcms?

I don't see how a configure check in GIMP would help plug-ins so the answer to the question doesn't really matter. I'll give it anway: I've added such a check a few minutes ago when the color proof display filter was added to CVS.

Great.
Thanks for this hint. I will see what I can do with it.

-- Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

would help plug-ins to easily link against liblcms?

I don't see how a configure check in GIMP would help plug-ins so the answer to the question doesn't really matter. I'll give it anway: I've added such a check a few minutes ago when the color proof display filter was added to CVS.

Great.
Thanks for this hint. I will see what I can do with it.

Hmm? As I already outlined, the configure check in GIMP doesn't help external plug-ins and modules. Also, GIMP does not depend on lcms now, so I wonder what exactly you are trying to do with it ...?

Sven

Am 24.11.03, 11:29 +0100 schrieb Sven Neumann:

Hmm? As I already outlined, the configure check in GIMP doesn't help external plug-ins and modules. Also, GIMP does not depend on lcms now, so I wonder what exactly you are trying to do with it ...?

I guessed You mean to set an variable which helps to set lcms paths and switches in the Makefile. For instance the separate plug-in from Alastair M. Robinson and the color-manager from Karl Heinz Kremer need to detect lcms separately from the main app. These are plug-ins helping to work with different colour spaces. Will they not included in gimps main release?

To my plans. As I was asked by users to make cinepaints tiffreader compile in gimp because of its multilayer capabilities I like to reach the most common behaviour. Recently I started to use lcms to convert undisplayable colour spaces to RGB. So I am now able to open CMYKs and Lab to an visible image. But it is not clear at the moment how to handle it at all. Maybe the upcoming CMS framework of gimp is an better solution to handle this. Next would be to apply an embedded profile to the image data and load the converted image into the app. This could help to justify the workspace. Other CMS issues stay on my plan. I found tiff has very good colour management capabilities, so I work mostly on supporting this format.

I liked to offer the compatible plug-in with all features of gimp plug-in and the additionals of cinepaint for gimps 2.0 realease. At the moment Recently a friend and I managed the plug-in to compile with gimp-1.3.23 .

This is part of what I plan to give back to gimp. To work for both apps at once makes it more likely that people will enjoy the advantages of tiff .

Hope this helps avoiding some further code duplication. Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

I guessed You mean to set an variable which helps to set lcms paths and switches in the Makefile. For instance the separate plug-in from Alastair M. Robinson and the color-manager from Karl Heinz Kremer need to detect lcms separately from the main app.

Separate plug-ins need to provide their own build framework. We make it relatively easy by providing pkg-config files, automake macros and a plug-in template. However third-party plug-ins and modules will need to check for lcms on their own. It's not really rocket science though and people can of course copy the check from GIMP's configure script.

These are plug-ins helping to work with different colour spaces. Will they not included in gimps main release?

They should probably be included at some point. Actually our goal was to move as much plug-ins out of the main distribution as possible and not to accept any new plug-ins. However since there's still no useable plug-in registry, we lately changed this policy and started to add plug-ins to the 1.3 tree.

However it's a bit late to still add plug-ins for 2.0 but we can start now to implement a reasonable CMS framework in plug-ins and modules and integrate these into the distribution for the 2.2 release.

To my plans. As I was asked by users to make cinepaints tiffreader compile in gimp because of its multilayer capabilities I like to reach the most common behaviour. Recently I started to use lcms to convert undisplayable colour spaces to RGB. So I am now able to open CMYKs and Lab to an visible image.

libtiff does these color conversions for you already. The GIMP tiff plug-in is able to read CMYK files, not sure about Lab. The ability to read multiple pages from TIFF files should be added to GIMP's standard TIFF plug-in. This is a frequently requested feature and we are waiting for a patch for quite some time already:

http://bugzilla.gnome.org/show_bug.cgi?id=66886

I liked to offer the compatible plug-in with all features of gimp plug-in and the additionals of cinepaint for gimps 2.0 realease. At the moment Recently a friend and I managed the plug-in to compile with gimp-1.3.23 .

As I said, it's a bit late to get this into 2.0. But it all depends on how large the changes are. I don't think we can integrate color management at this point but a clean patch for loading multiple pages could be accepted into 2.0 still.

Sven

Am 26.11.03, 12:32 +0100 schrieb Sven Neumann:

They should probably be included at some point. Actually our goal was to move as much plug-ins out of the main distribution as possible and not to accept any new plug-ins. However since there's still no useable plug-in registry, we lately changed this policy and started to add plug-ins to the 1.3 tree.

I understand.

However it's a bit late to still add plug-ins for 2.0 but we can start now to implement a reasonable CMS framework in plug-ins and modules and integrate these into the distribution for the 2.2 release.

The later sounds interessting.

convert undisplayable colour spaces to RGB. So I am now able to open CMYKs and Lab to an visible image.

libtiff does these color conversions for you already. The GIMP tiff

Yes, CMYK is converted natively by libtiff. The plug-in is able to do it with an embedded ICC profile. This may remain for the CMS framework of gimp You mentioned.

plug-in is able to read CMYK files, not sure about Lab. The ability to read multiple pages from TIFF files should be added to GIMP's standard TIFF plug-in. This is a frequently requested feature and we are waiting for a patch for quite some time already:

http://bugzilla.gnome.org/show_bug.cgi?id=66886

Loading it up with my login failed. Are there other ways to send it?

As I said, it's a bit late to get this into 2.0. But it all depends on how large the changes are. I don't think we can integrate color management at this point but a clean patch for loading multiple pages could be accepted into 2.0 still.

It is more a new plug-in in terms of size. My goal was not to split the code for different apps. So take a look on it yourselfe.

Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

http://bugzilla.gnome.org/show_bug.cgi?id=66886

Loading it up with my login failed. Are there other ways to send it?

Patches can be send to the gimp-developer mailing-list.

As I said, it's a bit late to get this into 2.0. But it all depends on how large the changes are. I don't think we can integrate color management at this point but a clean patch for loading multiple pages could be accepted into 2.0 still.

It is more a new plug-in in terms of size. My goal was not to split the code for different apps. So take a look on it yourselfe.

I don't think we want the replace the TIFF plug-in with a completely different version at this point of development. Too many bug-fixes went into the plug-in even since GIMP-1.2. We would risk to loose these. I would prefer a set of patches.

Sven

Hi,

Kai-Uwe Behrmann writes:

So here comes the gzipped code.

Non-gzipped would certainly have been preferred since it allows to comment on the code more easily.

The old bugs I had visited and all but one checked. I could not see the patch for 97352 TIFF plugin shows progress bar when run non-interactive . So this may remained open.

That bug was bogus anyway and the "fix" got reverted when be changed all plug-ins to do the right thing.

Your plug-in has some interesting parts like where it reads multiple TIFF pages and also the use of lcms to do the color conversion should be considered for inclusion in the GIMP plug-in. However we probably don't want to include a plug-in that will double the amount of #if and #ifdef statements in the GIMP source tree.

Are you or is anyone else interested in merging the interesting parts into the tiff plug-in as found in our CVS tree? If noone raises hand, I would do it myself. Not sure if the functionality that depends on lcms should be included before 2.0. I would suggest we start with adding support for multiple pages.

Sven

Am 26.11.03, 22:53 +0100 schrieb Sven Neumann:

Non-gzipped would certainly have been preferred since it allows to comment on the code more easily.

It would become ~140kB so I avoided unzipping for the list readers.

the patch for 97352 TIFF plugin shows progress bar when run

That bug was bogus anyway and the "fix" got reverted when be changed all plug-ins to do the right thing.

Fine to hear.

Your plug-in has some interesting parts like where it reads multiple TIFF pages and also the use of lcms to do the color conversion should be considered for inclusion in the GIMP plug-in. However we probably

Any testimages, which help showing weak points, I would like to see.

don't want to include a plug-in that will double the amount of #if and #ifdef statements in the GIMP source tree.

As I like to continue to develop this tiffreader, what would You think is appropriate to let the #if / #ifdef macros fall without erasing code? If You know how to avoid this I would change the code. One thing I imagine is to bring missed functions in the header and declare them likewise. The most part of lcms stuff and higher bit modes #if/def s would still remain. I dont like macros very much as they introduce another language. But I dont know how to change this.

Please consider I develop for 4 versions of the application (after gimp-2.0 for three). It is awful to copy the code from on plug-in to the next and the next and introducing as many bugs as possible. This would not be my goal.

Are you or is anyone else interested in merging the interesting parts into the tiff plug-in as found in our CVS tree? If noone raises hand, I would do it myself. Not sure if the functionality that depends on lcms should be included before 2.0. I would suggest we start with adding support for multiple pages.

I would help of removing spread comments. Thanks for going to include it.

regards Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

don't want to include a plug-in that will double the amount of #if and #ifdef statements in the GIMP source tree.

As I like to continue to develop this tiffreader, what would You think is appropriate to let the #if / #ifdef macros fall without erasing code?

There is no way a GIMP plug-in can support multiple versions and even a completely different app and at the same time be readable and maintainable code. In my opinion the version included with GIMP-2.0 should be a plug-in for GIMP-2.0 and nothing else. I also don't see why we should not continue to use our working TIFF plug-in. This plug-in works, is widely tested and has a maintainer. In my opinion what we should do is to integrate some functionality of your plug-in into the TIFF plug-in as found in CVS. I would suggest we start by adding support for multi-page TIFF file and look into color conversion routines as soon as GIMP-2.0 is released.

Sven

Hi,

Am 27.11.03, 13:42 +0100 schrieb Sven Neumann:

There is no way a GIMP plug-in can support multiple versions and even a completely different app and at the same time be readable and maintainable code. In my opinion the version included with GIMP-2.0 should be a plug-in for GIMP-2.0 and nothing else. I also don't see why we should not continue to use our working TIFF plug-in. This plug-in works, is widely tested and has a maintainer. In my opinion what we should do is to integrate some functionality of your plug-in into the TIFF plug-in as found in CVS. I would suggest we start by adding support for multi-page TIFF file and look into color conversion routines as soon as GIMP-2.0 is released.

If there are different maintainers for the two plug-ins it will become difficult to be up to date. Anyway, its fine to see something included in gimp.

Please take care of the layer offsets. They will become more important in the future for some panoramaists. The viewport is somewhat tricky but works. The visibility check should be ok.

The file reading makes several assumtions, which are done due to the lack of further examples and some holes in the spec.

If You copy code from my version to gimps one be carfully with any bit specific functions. They take different arguments. This is important if You plan to take over the TIFF-directory information structure I introduced. This structure is stored in the form of an double linked list and is intended to minimise libtiff calls.

Hope its not too hard to take over the changes You want. Kai-Uwe

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1

Kai-Uwe Behrmann wrote: | Hi,
|
| Am 27.11.03, 13:42 +0100 schrieb Sven Neumann: |
|
|>There is no way a GIMP plug-in can support multiple versions and even |>a completely different app and at the same time be readable and |>maintainable code. In my opinion the version included with GIMP-2.0 |>should be a plug-in for GIMP-2.0 and nothing else. I also don't see |>why we should not continue to use our working TIFF plug-in. This |>plug-in works, is widely tested and has a maintainer. In my opinion |>what we should do is to integrate some functionality of your plug-in |>into the TIFF plug-in as found in CVS. I would suggest we start by |>adding support for multi-page TIFF file and look into color conversion |>routines as soon as GIMP-2.0 is released.

Sven, I think what he was saying (and please speak up if I misinterpreted your english) that he would like to become the current maintainer of the current tiff plugin. I certainly see no reason why this person can't have responsibility over the current plugin as long as he doesn't revert the improvements made to the gimp-2.0 plugin.

Also, the best way of gettting rid of the #if's would be to put some app specific functionality into a seperate file and compile or include only one driver file for the tiffreader plugin. I am all for this. I suspect, though you haven't said, that you are also working on the CinePaint plug-in. It would be good to share as much code as possible between our projects, IMO.

At worse, you can put it all in the same file and #if away the block of fuctions specific to a certain app, which is _MUCH_ more readable then having #ifs in the middle of the code.

- -- Dan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQE/xjJkad4P1+ZAZk0RAtx5AJ4tIIAVULBetzp0XY8HeN11Z3GUagCgptEm LS/AmAijpqq/NggerS9q7xs=
=jSki
-----END PGP SIGNATURE-----

Hi,

Daniel Rogers writes:

Sven, I think what he was saying (and please speak up if I misinterpreted your english) that he would like to become the current maintainer of the current tiff plugin.

That is something the current maintainer of the plug-in has to decide.

I certainly see no reason why this person can't have responsibility over the current plugin as long as he doesn't revert the improvements made to the gimp-2.0 plugin.

I am certainly not trying to discourage anyone from taking responsibility.

Also, the best way of gettting rid of the #if's would be to put some app specific functionality into a seperate file and compile or include only one driver file for the tiffreader plugin. I am all for this. I suspect, though you haven't said, that you are also working on the CinePaint plug-in. It would be good to share as much code as possible between our projects, IMO.

Since both projects build on a different framework this attempt is IMO doomed to fail. Especially since judging from the project's roadmaps the two frameworks will continue to diverge in the future.

I really don't want to see this code replace the current tiff plug-in because I believe it will be a maintaince nightmare. When I grep the plug-in sources, I don't want to get hits from codepaths that aren't used by the GIMP version. When I review diffs I don't want to have to care about changes that aren't in our code.

If we would attempt to do this, it would be as if we would decide to keep plug-ins for gimp-1.3 and gimp-1.2 in the same branch in CVS. We could add #ifdef's for the parts where the APIs differ and so we wouldn't have to merge bug-fixes between the branches. Why aren't we doing this? Because it would be a nightmare to maintain. It's a lot easier to merge a change done in the HEAD branch to the gimp-1-2 branch and vice versa than it would be if you had to make sure you are doing the same fix in two branches of a preprocessor directive.

Anyone who would want to seriously work on this code would have to be able to compile the plug-in for all supported applications. This would put an insanely high burden on anyone willing to work on this plug-in.

At worse, you can put it all in the same file and #if away the block of fuctions specific to a certain app, which is _MUCH_ more readable then having #ifs in the middle of the code.

What you will end up with if go that way is basically what I suggest to have: One tiff.c file for The GIMP, a different tiff.c for CinePaint. IMO it will be easier to merge changes between two or more versions of the plug-in than to attempt to maintain one plug-in for two or more applications.

Please don't get me wrong. I am not trying to discourage anyone. On the contrary, I would welcome to see the projects share code and Kai-Uwe surely did some improvements to the tiff plug-in that we want to see in GIMP CVS more sooner than later. However I dislike the proposed way of doing this. IMO we should merge the improvements one by one. Later bug-fixes can be merged between the two projects based on patches. This will IMO be a lot more convenient.

Sven

Hello,

Am 28.11.03, 01:07 +0100 schrieb Sven Neumann:

Daniel Rogers writes:

Sven, I think what he was saying (and please speak up if I misinterpreted your english) that he would like to become the current maintainer of the current tiff plugin.

That is something the current maintainer of the plug-in has to decide.

I would be interessted in the current maintainers opinion related to this plug-in.

Also, the best way of gettting rid of the #if's would be to put some app specific functionality into a seperate file and compile or include only one driver file for the tiffreader plugin. I am all

Sounds good to me. This is something I would do to make the gimp specific parts easier to understand in one common plug-in.

for this. I suspect, though you haven't said, that you are also working on the CinePaint plug-in. It would be good to share as much code as possible between our projects, IMO.

Since both projects build on a different framework this attempt is IMO doomed to fail. Especially since judging from the project's roadmaps the two frameworks will continue to diverge in the future.

Robin Rowe installed an compatibility layer so nearly all gimp-1.2 plug-ins can compile. I think this is an essential step to make the distance of both applications smaller not greater. As long as we talk about plug-ins, why not use the common interface in both directions? For instance, to enable CinePaint support for the orientation tag in tiff, I am willing to add the missed flip PDB entry. I see there no problem.

I really don't want to see this code replace the current tiff plug-in because I believe it will be a maintaince nightmare. When I grep the plug-in sources, I don't want to get hits from codepaths that aren't used by the GIMP version. When I review diffs I don't want to have to care about changes that aren't in our code.

At the moment my tiff version could be more clear and it is hard to understand for others. So I offer to follow Daniels suggestions and separate GIMP and CinePaint things as described by him. So an differenciated working in both apps would become likely. I did only a first step toward supporting GIMP.

Anyone who would want to seriously work on this code would have to be able to compile the plug-in for all supported applications. This would put an insanely high burden on anyone willing to work on this plug-in.

It is up to the responsible maintainer, IMHO, to make changes compile in an specific application. I can imagine that something changed in the GIMP specific part will need some overwork by me for CinePaint or filmgimp (as long as I need the old gui).

At worse, you can put it all in the same file and #if away the block of fuctions specific to a certain app, which is _MUCH_ more readable then having #ifs in the middle of the code.

What you will end up with if go that way is basically what I suggest to have: One tiff.c file for The GIMP, a different tiff.c for CinePaint. IMO it will be easier to merge changes between two or more versions of the plug-in than to attempt to maintain one plug-in for two or more applications.

I work now over one year on this plug-in. The point for me is they diverged as I needed to fix things and added new capabilities. Many variable names changed. So it is harder to jump from one plug-in to the other. I did the big change with the CinePaint plug-in in order to adapt Nick Lamb s big overhaul. It took me much time after the merge to get the thing working again. Now there are many new things coming from my side.
Equal who does this work GIMPs maintainer or I, this will be much wasted time.
What I offer is to set up the base of an potential, maintainable, mostly common plug-in, with further need by me to make things more clear.

Please don't get me wrong. I am not trying to discourage anyone. On the contrary, I would welcome to see the projects share code and Kai-Uwe surely did some improvements to the tiff plug-in that we want to see in GIMP CVS more sooner than later. However I dislike the proposed way of doing this. IMO we should merge the improvements one by one. Later bug-fixes can be merged between the two projects based on patches. This will IMO be a lot more convenient.

I expect You try to avoid trouble coming from bugs which get introduced by a completely new plug-in. While adapting, You get a new plug-in either, which needs much debugging too. Otherwise You could erase all CinePaint specific parts and test and life with a new plug-in. This is not the badest thing.
Missed or lost features may be reworked together with the GIMP maintainer. This would really help of course.

The measure of my work is an test suite which needs to be solved. This is the most relyable thing I have. (Further unsolved test tiffs are welcome.)

regards
Kai-Uwe

Hi,

Kai-Uwe Behrmann writes:

Robin Rowe installed an compatibility layer so nearly all gimp-1.2 plug-ins can compile. I think this is an essential step to make the distance of both applications smaller not greater. As long as we talk about plug-ins, why not use the common interface in both directions? For instance, to enable CinePaint support for the orientation tag in tiff, I am willing to add the missed flip PDB entry. I see there no problem.

There might be a compatibility layer for GIMP-1.2 but the GIMP-2.0 API is different and I don't think backwards compatibility is our goal.

Anyone who would want to seriously work on this code would have to be able to compile the plug-in for all supported applications. This would put an insanely high burden on anyone willing to work on this plug-in.

It is up to the responsible maintainer, IMHO, to make changes compile in an specific application. I can imagine that something changed in the GIMP specific part will need some overwork by me for CinePaint or filmgimp (as long as I need the old gui).

So why should the code be shared then? If it needs manual interaction, it will be a lot easier to merge changes betwenn two separate files than to keep two versions in the same file consistent. I am very serious about this.

What you will end up with if go that way is basically what I suggest to have: One tiff.c file for The GIMP, a different tiff.c for CinePaint. IMO it will be easier to merge changes between two or more versions of the plug-in than to attempt to maintain one plug-in for two or more applications.

I work now over one year on this plug-in. The point for me is they diverged as I needed to fix things and added new capabilities. Many variable names changed. So it is harder to jump from one plug-in to the other. I did the big change with the CinePaint plug-in in order to adapt Nick Lamb s big overhaul. It took me much time after the merge to get the thing working again. Now there are many new things coming from my side. Equal who does this work GIMPs maintainer or I, this will be much wasted time. What I offer is to set up the base of an potential, maintainable, mostly common plug-in, with further need by me to make things more clear.

I agree that it makes sense to make the code for the two plug-ins more common since it will make it easier to merge changes between the two but I am not going to accept any ifdef's in GIMP CVS that aren't strictly necessary for the GIMP plug-in alone.

Sven

Hi Sven and tiff maintainer,

Am 28.11.03, 15:00 +0100 schrieb Sven Neumann:

I agree that it makes sense to make the code for the two plug-ins more common since it will make it easier to merge changes between the two but I am not going to accept any ifdef's in GIMP CVS that aren't strictly necessary for the GIMP plug-in alone.

Ok, I would like to do some cleaning and come with an more clear version of tiff . This version will include only GIMP specific stuff. As I see Your interesst, I think it is worth finding an good start place.

What does the tiff maintainer say about this?

regards Kai-Uwe

Hi Sven and tiff maintainer,

Am 28.11.03, 15:00 +0100 schrieb Sven Neumann:

I agree that it makes sense to make the code for the two plug-ins more common since it will make it easier to merge changes between the two but I am not going to accept any ifdef's in GIMP CVS that aren't strictly necessary for the GIMP plug-in alone.

Ok, I would like to do some cleaning and come with an more clear version of tiff . This version will include only GIMP specific stuff. As I see Your interesst, I think it is worth finding an good start place.

What does the tiff maintainer say about this?

regards Kai-Uwe

PS: My post seems not to be tight enough to reach every time this list.

Hi Sven and tiff maintainer,

Am 28.11.03, 15:00 +0100 schrieb Sven Neumann:

I agree that it makes sense to make the code for the two plug-ins more common since it will make it easier to merge changes between the two but I am not going to accept any ifdef's in GIMP CVS that aren't strictly necessary for the GIMP plug-in alone.

Ok, I would like to do some cleaning and come with an more clear version of tiff . This version will include only GIMP specific stuff. As I see Your interesst, I think it is worth finding an good start place.

What does the tiff maintainer say about this?

regards Kai-Uwe

PS: My post seems not to be tight enough to reach every time this list.