Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.

[Kai-Uwe Behrmann]

... 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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: [Gimp-user] Re: Fwd: [GUG] CMYK under Gimp.

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp. (fwd)

[Kai-Uwe Behrmann]

I resend this email, as it was lost by the lists.xcf.berkeley.edu
mailserver.

-- Forwarded message --
Date: Mon, 24 Nov 2003 11:03:41 +0100 (CET)
From: Kai-Uwe Behrmann <[EMAIL PROTECTED]>
To: Sven Neumann <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED]
Subject: Re: [Gimp-developer] Fwd: [GUG] CMYK under Gimp.

Hi,

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

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

That was my surprise and hope some time ago too. I looked in the man pages
and found only some rudimentary entries describing how to convert single
colour for the colour selction. I am not aware of any mechanism on how to
send Lab or Yuv or something else directly to X for displaying. And I did
not found any mechanism on telling X which is the correct monitor profile.
This I would call colour management.

regards
Kai-Uwe


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] ANNOUNCE: The GIMP 1.3.23

[Kai-Uwe Behrmann]

Am 24.11.03, 12:58 +0100 schrieb David Neary:

> Overview of Changes in GIMP 1.3.23
> ==
> - Color proof display filter using ICC profiles written by Banlu
>   Kemiyatorn

Looks promising. Thanks

Kai-Uwe

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMS under Gimp.

[Kai-Uwe Behrmann]

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


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMS under Gimp.

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

Am 26.11.03, 14:38 +0100 schrieb Sven Neumann:

> > Loading it up with my login failed. Are there other ways to send it?
>
> Patches can be send to the gimp-developer mailing-list.

So here comes the gzipped code.

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.

regards
Kai-Uwe Behrmann


tiff.c.gz
Description: tiff.c.gz
___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

Hello,

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

> Daniel Rogers <[EMAIL PROTECTED]> 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

___
Gimp-developer mailing list
[EMAIL PROTECTED]

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

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.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] multilayer tiff

[Kai-Uwe Behrmann]

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.

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] preparing GIMP 2.2

[Kai-Uwe Behrmann]

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 :[EMAIL PROTECTED]


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMS PDBs in CinePaint/GIMP

[Kai-Uwe Behrmann]

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 :[EMAIL PROTECTED]


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

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMS PDBs in CinePaint/GIMP

[Kai-Uwe Behrmann]

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 <[EMAIL PROTECTED]> 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
>


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] CMS PDBs in CinePaint/GIMP

[Kai-Uwe Behrmann]

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 <[EMAIL PROTECTED]> 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
>


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Re: Gimp-developer Digest, Vol 29, Issue 13

[Kai-Uwe Behrmann]

Am 08.02.05, 20:38 +0100 schrieb Jordi CantÃn:

> I accept suggestions to change this. As Gimp color management is going to be
> centralized,what will be the official default directory for the color
> profiles? Is it already set?
 
The more system wide discussions are going on at the lcms and the OpenICC 
mailing lists. You can follow the link to the ICC path discussion results
<http://bugs.freestandards.org/show_bug.cgi?id=77>

regards
Kai-Uwe Behrmann
+ development for color management 
+ imaging / panoramas
+ email: [EMAIL PROTECTED]
+ http://www.behrmann.name
___
Gimp-developer mailing list
Gimp-developer@lists.xcf.berkeley.edu
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] Re: [Gimp-print-devel] ANNOUNCE: Gutenprint 5.0.0-rc1

[Kai-Uwe Behrmann]

Hello,

this version compiles into CinePaint after runing configure without 
any further change.


Thanks

regards
Kai-Uwe Behrmann
+ development for color management 
+ imaging / panoramas
+ email: [EMAIL PROTECTED]
+ http://www.behrmann.name


Am 01.09.05, 21:56 -0400 schrieb Robert L Krawitz:

> Welcome to Gutenprint 5.0.0-rc1!  Please read these release notes
> carefully.
> 
> Gutenprint, formerly named Gimp-Print, is a suite of printer drivers
> that may be used with most common UNIX print spooling systems,
> including CUPS, lpr, LPRng, or others.  These drivers provide high
> quality printing for UNIX (including Macintosh OS X 10.2, 10.3, and
> 10.4) and Linux systems that in many cases equal or exceed proprietary
> vendor-supplied drivers in quality and functionality, and can be used
> for demanding printing tasks requiring flexibility and high quality.
> This software package includes the Print plug-in for the GIMP and
> Ghostscript and CUPS drivers, as well as Foomatic data.
> 
> The package has been renamed in order to clearly distinguish it from
> the GIMP.  While this package started out as the Print plugin for the
> GIMP, it has expanded into a collection of general purpose printer
> drivers, and the Print plugin for the GIMP is now only a small (but
> important) piece of the package.  Furthermore, the name Gutenprint
> recognizes Johannes Gutenberg, the inventor of the movable type
> printing press.  Finally, the word "guten" means "good" in German.
> 
> Gutenprint 5.0.0-rc1 is the first release candidate of Gutenprint 5.0.
> It is based on the Gimp-Print 4.3 series that has been in development
> for over three years, and includes many improvements over the very
> popular 4.2 series.  This release is believed to be quite stable, but
> further testing is required before final release.  We believe this
> release to be stable enough for day to day use, and encourage people
> to test it and report their results.
> 
> Gutenprint currently contains over 200 drivers supporting in excess of
> 600 printer models.
> 
> The Print plug-in for the GIMP requires the GIMP 1.2.3 or above on the
> 1.2 line (1.2.5 is recommended), or the GIMP 2.0 or above.  You may
> need to install packages named "gimp-devel", "gtk-devel", and
> "glib-devel" (or similar equivalents) on many systems.  This plug-in
> will work with any printing system, and offers a comprehensive user
> interface to control all aspects of the printing process.
> 
> The CUPS driver requires CUPS 1.1.15 or higher.  You may need to
> install a package named "cups-devel" or similar on many systems.
> Please the rest of the release notes, in particular the Exceptions and
> Workarounds, for full details on installation, as there is an
> important caveat.  CUPS is the printing system used on Macintosh OS X
> 10.2 and above, and many other systems use it.  The combination of
> CUPS and Gutenprint provides a flexible, general purpose printing
> system capable of producing the highest quality output with any of the
> printers supported by this package.  We strongly recommend using CUPS
> with Gutenprint as a general-purpose printing solution.
> 
> The Ghostscript driver requires GNU Ghostscript 6.53 or higher, ESP
> Ghostscript 7.05 or higher, or AFPL Ghostscript 7.04 or higher.  It
> uses the IJS package included with these versions of Ghostscript to
> create a driver that may be built much more easily than traditional
> Ghostscript drivers.  The options for this driver are very complex,
> and it is normally used with the Foomatic driver integration system.
> 
> Users of Macintosh OS X 10.2 (Jaguar), 10.3 (Panther), and 10.4
> (Tiger) can use this package, as the printing system is based on CUPS.
> For ease of installation, a pre-built package with installer is
> normally supplied a few days after the release of the source package.
> We highly recommend that OS X users use the pre-built package rather
> than attempt to build it themselves.
> 
> NOTE: This package will not work with any version of OS X 10.0 and
> 10.1 (such as 10.1.5), as those systems do not use CUPS as their
> printing system.  This is NOT going to be fixed; you must upgrade to
> at least OS X 10.2 in order to use this package.  The reason why is
> that OS X 10.2 and above use CUPS as the basis of the printing system.
> OS X 10.0 and 10.1 use a different system that would require a
> separate driver, and we do not plan to write that driver.
> 
> The README file included with this package provides full instructions
> on building and installing Gutenprint.
> 
> * Major changes be

Re: [Gimp-developer] CMM

[Kai-Uwe Behrmann]

Am 17.02.06, 11:15 +0100 schrieb Andreas Klafft:

> In the GIMP I see only the implementation of the lcms-lib. This is not a
> starting point, this is nothing. Because you don't see really, what you do. I

lcms is open source. What would you expect to see more?

Mit freundlichen Grüßen
Kai-Uwe Behrmann
+ Programmierung für
+ Farbmanagement / Bilder / Panoramen
+ http://www.behrmann.name
+ email: [EMAIL PROTECTED]

___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] crash after saving tif

[Kai-Uwe Behrmann]

Similiar problems where reported for CinePaint. Look at your libtiff 
version. If it has 3.8.0 update or downgrad. This libtiff version is 
buggy.

Hopd this helps.

kind regards
Kai-Uwe Behrmann
+ development for color management 
+ imaging / panoramas
+ email: [EMAIL PROTECTED]
+ http://www.behrmann.name


Am 25.03.06, 01:19 -0300 schrieb Roberto Winter:

> hi.
> 
> as i saved a file just now gimp crashed. i had it built from cvs some 10
> days ago (gcc 3.3.5).
> i'm using debian unstable, e16 window manager, nvidia drivers 8178 on xorg
> and kernel 2.6.13.1 .
> 
> on the terminal i got:
> 
> file_save_dialog_check_uri: URI =
> file:///home/media/fotos_tangara/xcf/tif/IMG_6384.TIF
> 
> file_save_dialog_check_uri: basename = IMG_6384.TIF
> file_save_dialog_check_uri: selected save_proc: NULL
> file_save_dialog_check_uri: URI save_proc: TIFF image
> file_save_dialog_check_uri: basename save_proc: TIFF image
> 
> file_save_dialog_check_uri: no save_proc was selected from the list
> file_save_dialog_check_uri: use URI's proc 'TIFF image' so indirect saving
> works
> *** glibc detected *** corrupted double-linked list: 0x0a86a390 ***
> /opt/gimp/bin/gimp-2.3: terminated: Aborted
> 
> (script-fu:4033): LibGimpBase-WARNING **: script-fu: wire_read(): error
> 
> the image is a 8Mp photograph. it was a single layer file.
> 
> is this known? should i report a bug (i suspect it might be something with
> my environment, not gimp)? has it been noticed? fixed?
> the thing is it had been running absolutely stable the last days. and the
> weirder is that it crashed while doing something that i do often (saving as
> tif).
> another thing that might matter is that the file was written fine and is not
> corrupted (~10Mb in size).
> 
> thanks for any help,
> roberto
> 
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Why modules interface?

[Kai-Uwe Behrmann]

Am 22.01.03, 16:59 +0100 schrieb Michael Natterer:

> "Austin Donnelly" <[EMAIL PROTECTED]> writes:
>
> > > I want to add some features (changeing the gamma of the display ...) to
> > > filmgimp.
> >
> > There already is a module called "cdisplay-gamma" which can do this.  You
> > don't need to write any code, just use this pre-existing module.
>
> The best idea IMHO would be to drop this silly film-gimp code
> duplication and help coding on gimp 1.4 (which already has this
> feature).

Of course one programm would be fine for developing together. At the
moment many people await the gimp-2.0 with gegl and 16bit, floats, cmyk,
CIE Lab ...

Filmgimp is near to the above mentioned colordepths. Therefore I decided
to programm for it.

> ciao,
> --mitch
>

regards
Kai-Uwe

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] (fwd) GIMP CMYK Devloper - Willing to Pay

[Kai-Uwe Behrmann]

Hi,
Even I'm not an educated programmer, I have staying cmyk on my plans for
gimp. My reason is to get my own photos out for printing and let my
printer sensible show the colors I missed for long time on paper.
(Same should be with offset printing ... )
There are two targets for me:
- integrate RGB -> CMYK via lcms 
  (include gamut checking, select of the right profiles ...)
- interface tiff / gimp-print - for exporting and for directly printing

This is longterm, because I'm workless at the moment and try to get some
money otherway (VR). If there is an interest to speed this up, I would be
glad. Please consider other authors too, wich may have more experience
with this like Karl-Heinz Kremer<[EMAIL PROTECTED]> or
Martí Maria<[EMAIL PROTECTED]> wich I just remember.

For more longterm I await gegl interfaced in gimp ;-)

regards
Kai-Uwe

Am 14.02.03, 12:12 +0100 schrieb Sven Neumann:

> Hi,
>
> Branko Collin <[EMAIL PROTECTED]> writes:
>
> > I saw the following in comp.graphics.apps.gimp.
> >
> >   Branko
> >
> > On Thu, 13 Feb 2003 21:13:44 -0500, in comp.graphics.apps.gimp Ruben
> > <[EMAIL PROTECTED]> wrote:
> >
> > >NYLXS is willing to sponser a real CMYK filter for the GIMP.  If anyone
> > >is interested in doing this, please email me with estimated cost.
>
> now what is a "real CMYK filter" ?
>
>
> Salut, Sven
>

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

[Gimp-developer] interaction gimp <-> plug-in

[Kai-Uwe Behrmann]

Hi,
I want add an feature to imagemap.
I have in the plug-in an shape ( circle, rectangle, poly ) and want this
as an selection in gimp in the belonging image. This selection can then be
beveled or lighten as hotspotimage for the html-map tag.
Can somebody show me, how to tell gimp:  make the selection
   select_rec(a,b,c,d)  ?

Is there an interface, to talk from an plug-in back to gimp, other than
finishing the plug-in? Sorry I did'nt found such example in the doc.

thanks
Kai-Uwe


___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer

Re: [Gimp-developer] Proposal for protesting against softwarepatents in Europe

[Kai-Uwe Behrmann]

Hi Raphaël,

my wishes are with You and this protest.

Kai-Uwe Behrmann


Am 26.08.03, 15:07 +0200 schrieb Raphaël Quinet:

> Well, this may be a bit controversial, but I thought about supporting
> the demonstration against software patents in Europe by replacing the
> GIMP home page by the following page:
>   http://www.gimp.org/nopatents.html
> I prepared that page a couple of days ago, but now I see that the
> announcement about the protest has been posted on Slashdot and several
> other sites.  So maybe it is time to put it on the home page, unless
> most people here are against this kind of online protest.  The GIMP
> web site is in the U.S. so this may not be so relevant.  But on the
> other hand, several of the most active GIMP developers are living and
> working in Europe.
>
> Is anybody against that kind of action on the GIMP web site?  If there
> is any strong opposition against it, then there is no need to have a
> long debate: I will simply forget about it.  Otherwise, I would like
> to replace the home page of www.gimp.org later today (let's say in
> three or four hours).
>
> -Raphaël
> ___
> Gimp-developer mailing list
> [EMAIL PROTECTED]
> http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
>

___
Gimp-developer mailing list
[EMAIL PROTECTED]
http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer