Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread David Gowers
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz j...@joncruz.org wrote: However, the answer to the base question is Yes, X and Gtk support that to a very good degree, and all the low-level API's support delivering all the required information. and No, X does nothing with the colorspaces. It is left

Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-13 Thread yahvuu
David Gowers wrote: * Color selector colors must be stored in a profile independent colorspace (LAB?[1]). This ensures that we can paint any color onto any image and get the right result. Otherwise, we'd have to know the profile that the color was specified in, in order to use the correct

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread yahvuu
Christopher Curtis wrote: What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does monitor profile take this into account? Following the logic of the diagram, i'd say yes: your case is equivalent to cutting an image into two pieces and printing one piece

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Christopher Curtis
On Sat, Feb 13, 2010 at 5:39 AM, yahvuu yah...@gmail.com wrote: Christopher Curtis wrote: What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD?  Does monitor profile take this into account? Following the logic of the diagram, i'd say yes: your case is

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Hal V. Engel
On Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote: On Sat, Feb 13, 2010 at 5:39 AM, yahvuu yah...@gmail.com wrote: Christopher Curtis wrote: What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does monitor profile take this into account?

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Jon Cruz
On Feb 13, 2010, at 9:42 AM, Hal V. Engel wrote: I some ways I agree with Chris but the X.Org developers have insisted on an ongoing basis that it is NOT their responsibility to handle color management of the display. If we wait for X.Org to implement CM it will likely never happen.

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Christopher Curtis
On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz j...@joncruz.org wrote: [...] does seem to come down to the points that X11 does not and should not deal with color management in these regards and needs to leave it to the individual apps. To get a fully usable system, X11 would require some major

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Graeme Gill
David Gowers wrote: Imo the video card is the correct handler of these issues. X should just upload an appropriate lookup table (which is functionality already available in X, but doesn't happen automatically). Presumably a multihead video card allows multiple LUTs. From that point of view,

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-13 Thread Graeme Gill
Christopher Curtis wrote: On a more philosophical note, how does one represent a color that does not exist on a display but does on an output device? Do we make the assumption that the display always has the widest gamut? (I.e: GIMP will never run on a mono/CGA device and print to a CMYK

[Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread yahvuu
Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png While not yet a set of uses cases, i think these diagrams will be useful when discussing the use cases. Please let me know in case you spot errors or think i

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 04:55 PM, yahvuu wrote: Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1 is incorrect: All images in GIMP will have a color profile. This will either be the implicit sRGB

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Martin Nordholts
On 02/12/2010 06:27 PM, Omari Stephens wrote: On 02/12/2010 04:55 PM, yahvuu wrote: Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1 is incorrect: All images in GIMP will have a color

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Alexandre Prokoudine
On Fri, Feb 12, 2010 at 8:36 PM, Martin Nordholts wrote: People will want to create unmanaged images without a color profile for use on the web That is, if people want to make everyone's lives more difficult, who are we to stop them from doing so? :) Just make web equal to sRGB as it already

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread yahvuu
hi, and thanks for the feedback Omari Stephens wrote: I believe number 1 is incorrect: First thing to note is that i should have added a legend: - grey: device-dependent colors, plain RGB values, no profile info available. - orange: colors from an absolute color space Picture 1) was

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 05:36 PM, Martin Nordholts wrote: On 02/12/2010 06:27 PM, Omari Stephens wrote: On 02/12/2010 04:55 PM, yahvuu wrote: Hi, here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png I believe number 1

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Martin Nordholts
On 02/12/2010 07:18 PM, Omari Stephens wrote: If the user with a weird monitor (wide-gamut, AdobeRGB, or other) has a display profile and opens an image-without-profile, what do we display? We can't apply the display profile unless the image has some source color profile to link to the

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Christopher Curtis
On Fri, Feb 12, 2010 at 11:55 AM, yahvuu yah...@gmail.com wrote: here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png What happens in a multi-head setup when I maximize an image over (say) a CRT and an LCD? Does

Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-12 Thread SHIRAKAWA Akira
On 2010-02-09 19:52, Martin Nordholts wrote: GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content. Also don't forget that the various color picker/selectors aren't color managed at the moment, so selected colors (FG/BG

Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-12 Thread David Gowers
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira shirakawa.ak...@gmail.com wrote: On 2010-02-09 19:52, Martin Nordholts wrote: GIMP is nearly flawless in its color handling, but there is one problem. It forgets to convert copy and pasted image content. Also don't forget that the various color

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Omari Stephens
On 02/12/2010 10:12 PM, Christopher Curtis wrote: On Fri, Feb 12, 2010 at 11:55 AM, yahvuuyah...@gmail.com wrote: here are some diagrams depicting selected configurations for colormanagement: http://yahvuu.files.wordpress.com/2009/08/dataflow.png What happens in a multi-head setup when I

Re: [Gimp-developer] Color management dataflow [was: Color management (UI perspective for GIMP 2.8)]

2010-02-12 Thread Jon Cruz
On Feb 12, 2010, at 5:42 PM, Omari Stephens wrote: On 02/12/2010 10:12 PM, Christopher Curtis wrote: On Fri, Feb 12, 2010 at 11:55 AM, yahvuuyah...@gmail.com wrote: here are some diagrams depicting selected configurations for colormanagement:

Re: [Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-09 Thread Martin Nordholts
On 02/08/2010 07:07 PM, yahvuu wrote: From the User Scenarios [1], i'd like to pick Creating Original Art, short name: create a collage. This seems to be the clearest case, and perhaps the others can be modelled after this one. Compositing several images into one image requires that all parts

[Gimp-developer] Color management (UI perspective for GIMP 2.8)

2010-02-08 Thread yahvuu
hi all, this is work in progress, mostly in analysis stage and a bit chaotic, but there are already some conclusions which might be worth discussing. any comments appreciated, yahvuu From the product vision follows a tightly coupled workflow as default, where each file should have a profile

Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-17 Thread Sven Neumann
Hi, On Wed, 2007-01-17 at 09:45 -0500, Christopher Curtis wrote: Something to consider, I think, is momentum. I think that people want to be part of a vibrant developer community. If a project does not have this, it may be beneficial to create an artificial one by increasing the number of

Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-16 Thread Alexandre Prokoudine
On 1/16/07, Sven Neumann wrote: We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color management to the 2.6 release. Is 2.6 going to be bugfix release or a first stable version using GEGL/babl? Alexandre

Re: [Gimp-developer] color management

2007-01-16 Thread Alexandre Prokoudine
On 1/13/07, Sven Neumann wrote: I thought about having it in 2.4 but I think it's probably best distributed seperately until we find the time to integrate it properly. Since we are almost ready for 2.4, we should probably not add any new plug-ins at this point. Makes sense. 3. Is it

Re: [Gimp-developer] color management

2007-01-16 Thread Alexander Rabtchevich
It is located at [WINDOWS]\system32\spool\drivers\color\ at least on 2000+ Sven Neumann wrote: Hi, On Tue, 2007-01-16 at 11:23 +0300, Alexandre Prokoudine wrote: Is it possible to at least default to /usr/share/color/icc or ~/.color/icc on unixes in current dialog? The profile file

[Gimp-developer] Color management preferences not working and other CM stuff

2007-01-15 Thread Hal V. Engel
I just built GIMP from subversion trunk. This did fix the lcms plugin error. But on my system the color management preferences are not working. Specifically when I try to change any of the profiles there are significant issues. At first I though that perhaps my configuration was corrupted

Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-15 Thread Frédéric
On Tuesday 16 January 2007 03:45, Hal V. Engel wrote: 3. The file dialog does not have a way to show hidden directories that I have been able to find other than typing in the path.  This is probably a GTK issue rather than a GIMP issue. Just right-click on the file list and you'll see a

Re: [Gimp-developer] Color management preferences not working and other CM stuff

2007-01-15 Thread Sven Neumann
Hi, some of these things will be fixed for 2.4. But we can't delay the release any further and this means that color management is not going to be fully functional and usable in 2.4. We plan to have 2.6 out shortly after so I am currently postponing pretty much everything related to color

Re: [Gimp-developer] color management

2007-01-14 Thread Yoshinori Yamakawa
Hi, The functions included in Separate+ are jointly used, so I think that it is appropriate that those are placed in the same submenu. I don't understand where the Separate menu should be placed. However, I don't have the sense of incompatibility very much even if it is in a present place.

[Gimp-developer] color management

2007-01-13 Thread Alexandre Prokoudine
Hi, Since Sven proposed discussing 2.4 in mailing list and none of my questions/proposals are reflected in the bugzilla, here they are. Before you read any further, please note that I'm not trying to look smarter than you, I'm just initiating discussion ;-) Please prove me wrong where I am wrong.

Re: [Gimp-developer] color management

2007-01-13 Thread Sven Neumann
Hi, On Sat, 2007-01-13 at 13:35 +0300, Alexandre Prokoudine wrote: 1. Is it planned to have separate+ as part of 2.4? There was some mentioning of it in gimp-developer@, but the thread came from some other mailing list or a private discussion, so no clues. I thought about having it in 2.4

Re: [Gimp-developer] Color management -- softproof comments

2006-09-20 Thread Sven Neumann
Hi, On Mon, 2006-09-18 at 21:40 +0200, Peter Karp wrote: I assume that RGB and CMYK space are the default spaces for new pictures and that it can be assigend to untagged pictures? For what is CMYK space used when Gimp does not support CMYK editing of files or have I overseen that this will

[Gimp-developer] Color management -- softproof comments

2006-09-18 Thread Peter Karp
Hi, I'm new to this list and just wanted to share some ideas and findings I have. I tried Gimp 2.3.11 for Windows. I don't have the option to compile gimp myself. This was the latest win binary I found. I hope the descritpions from me make sense, because I used the german version and I'm not

Re: [Gimp-developer] Color Management

2005-08-13 Thread Jay Cox
On Mon, 2005-08-08 at 23:31 -0700, Hal V. Engel wrote: snip View == Print Simulation (or SoftProof or Proof Setup?) (currently is located in View == Display Filters which is confusing) Simulation (SoftProof or Proof?) Mode on or off (radio button or check box) Printer

Re: [Gimp-developer] Color Management

2005-08-13 Thread Alastair M. Robinson
Hi, Jay Cox wrote: Black point compensation is not a part of the ICC specification and is not currently available in any icc library that I know of. For the record: Black Point Compensation is supported by LCMS - you just supply a flag when building the transform... All the best, --

Re: [Gimp-developer] Color Management

2005-08-09 Thread Hal V. Engel
On Saturday 15 January 2005 05:37 pm, Sven Neumann wrote: snip Let's try to implement this in small steps then. As a first step I would like to add a couple of options to the preferences to allow users to define default locations for color profiles, to enable/disable color management and to

Re: [Gimp-developer] Color Management

2005-08-09 Thread Sven Neumann
Hi, interesting how much effort is being spent lately on reiterating what still needs to be done on color management. I think we have made a rather detailed list of required changes for GIMP 2.4 and obviously it's not quite there yet. I will get back to color management as soon as the new

Re: [Gimp-developer] Color Management

2005-08-09 Thread Francisco Bernal
I reiter my desire to work in that modules. But do not have time to play the game of the bugs to learn the basis of the gimp programming. /*--*/ If quality is important, sRGB is not an option (From the European Color Initiative web page www.eci.org) Francisco

[Gimp-developer] color management

2005-02-06 Thread Sven Neumann
Hi, just wanted to let everyone interested know that I started to add code for color management to GIMP CVS. For now, all we have is a configuration object that is supposed to be visible by the core, modules and plug-ins. This is based on a patch that Stefan Dhla mailed me last year. The next

Re: [Gimp-developer] Color Management was GEGL development/gimp integration

2005-01-15 Thread Gerhard Gaußling
Am Samstag 15 Januar 2005 23:42 schrieb Gerhard Gaußling: Photoshop lets pop up a dialog where the user can decide the kind of conversion he will do for the pasted/dragged image Of course only if the source color space of the imported (pasted/dragged) image is different from the working color

Re: [Gimp-developer] Color Management was GEGL development/gimp integration

2005-01-04 Thread Sven Neumann
Hi, Hal V. Engel [EMAIL PROTECTED] writes: I didn't think we were talking about user interface issues. Rather this is about how the image data is handled while it is being manipulated by the GIMP. Specifically should there be a color space transformation as part of loading the image and

Re: [Gimp-developer] Color Management

2004-08-20 Thread Sven Neumann
Hi, [EMAIL PROTECTED] [EMAIL PROTECTED] writes: The display filter for gamma is nice, but it should be accompanied by some linear adjustment of brightness and contrast. (That contrast filter that's there just doesn't do the trick!) That contrast filter is not meant to be used for

Re: [Gimp-developer] Color Management

2004-08-19 Thread [EMAIL PROTECTED]
The display filter for gamma is nice, but it should be accompanied by some linear adjustment of brightness and contrast. (That contrast filter that's there just doesn't do the trick!) I looked into using ICC profiles, but that would be too difficult to adjust easily. Perhaps a mechanism for

Re: [Gimp-developer] Color Management

2004-08-15 Thread Sven Neumann
Hi, [EMAIL PROTECTED] [EMAIL PROTECTED] writes: What's the easy way to get an ICC color profile? I'd like to look at an image on my display and on the wall simultaneously and tweak the profile until the display matches the wall. But I don't see any kind of GUI to accomplish this. Do I

Re: [Gimp-developer] Color Management

2004-08-14 Thread Sven Neumann
Hi, [EMAIL PROTECTED] [EMAIL PROTECTED] writes: I use GIMP to touch up photos before projecting them on a wall. The washed out effect of a projector might be nice to see while editing the image on a different device. (i.e. use a filter to preview approximately what it would look like

Re: [Gimp-developer] Color Management

2004-08-14 Thread [EMAIL PROTECTED]
] I use GIMP to touch up photos before projecting ] them on a wall. The washed out effect of a projector ] might be nice to see while editing the image on ] a different device. (i.e. use a filter to preview ] approximately what it would look like being viewed ] with a different device). ]

[Gimp-developer] Color Management

2004-08-13 Thread [EMAIL PROTECTED]
I use GIMP to touch up photos before projecting them on a wall. The washed out effect of a projector might be nice to see while editing the image on a different device. (i.e. use a filter to preview approximately what it would look like being viewed with a different device). Maybe this is

Re: [Gimp-developer] Color management: conclusions?

2004-07-29 Thread David Neary
Hi, Sven Neumann wrote: Alastair M. Robinson [EMAIL PROTECTED] writes: Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? The plug-in can attach a persistent parasite to gimp.

Re: [Gimp-developer] Color management: conclusions?

2004-07-29 Thread Sven Neumann
Hi, David Neary [EMAIL PROTECTED] writes: Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? The plug-in can attach a persistent parasite to gimp. Are parasites ever

Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi, I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? Sven ___

Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread David Neary
Hi, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I would. I assumed you were asking

Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi, David Neary [EMAIL PROTECTED] writes: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I would. I

Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Alastair M. Robinson
Hi Sven, Sven Neumann wrote: I wrote this in an earlier mail already but perhaps you didn't notice, so here's my question again: Sorry, yes I did miss that... I wonder if we should add the separate plug-in to the GIMP tarball for GIMP 2.2. Would you like to see that happening? I'd be delighted -

Re: [Gimp-developer] Color management: conclusions?

2004-07-28 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: Finally, a question: How is a plugin supposed to go about storing persistent data between sessions (i.e. in my case, the filenames of the profiles last used)? The plug-in can attach a persistent parasite to gimp. Sven

Re: [Gimp-developer] Color management: conclusions?

2004-07-24 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: Sure, but the plugin will depend on the implementation of the other stages. The guts of the plugin, thanks to lcms, will be pretty trivial - far simpler than the separate plugin; the most important factor will be the design of its user

Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread William Skaggs
So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a Color Management page to the Preferences. Step 2: Add enable/disable color management and working colorspace options to the page. To start with, sRGB will be the only option for the latter, but the

Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread Sven Neumann
Hi, William Skaggs [EMAIL PROTECTED] writes: So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a Color Management page to the Preferences. Step 2: Add enable/disable color management and working colorspace options to the page. To start with, sRGB

Re: [Gimp-developer] Color management: conclusions?

2004-07-22 Thread Alastair M. Robinson
Hi Sven, Sven Neumann wrote: William Skaggs [EMAIL PROTECTED] writes: So at the most concrete possible level, here is a suggestion on how to start: Step 1: Add a Color Management page to the Preferences. Step 2: Add enable/disable color management and working colorspace options to the page. To

[Gimp-developer] Color management (addendum)

2004-07-21 Thread Dave Neary
Hi all, Here's how cinepaint is doing color management: http://cinepaint.bigasterisk.com/CinePaintColourManagementUserDocumentation The page is a number of usecases, explaining what happens in each case. It is basically similar to many of the things that we have been saying, perhaps a little

[Gimp-developer] Color management: conclusions?

2004-07-20 Thread David Neary
Hi all, So as I was saying on gimp-user, we have had a really good chat about this now, but it seems that we are still unclear about what we hope to do in the area of colour management between now and 2.2. Who is prepared to put some time (perhaps a lot) into implementing this? What exactly

Re: [Gimp-developer] Color management: conclusions?

2004-07-20 Thread Sven Neumann
Hi, David Neary [EMAIL PROTECTED] writes: The two propositions are (or seem to be): 1) Apply embedded profiles (after prompting the user whether they would like to do that) at load time, or attach the profile to the image at load time and use the raw image data, assuming that sRGB (or

Re: [Gimp-developer] color management

2004-07-13 Thread Stefan Klein
David, So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? how about attaching a profile to each image? Correction is then done using the individual image's profile and the

Re: [Gimp-developer] color management

2004-07-12 Thread Øyvind Kolås
I haven't read the whole thread, but the last mail in the thread by William Skaggs seems very similar to the ideas discussed at gimpcon, what follows is my own understanding of what we discussed there: assuming working space of gimp == sRGB new image parasite_set (export_profile, sRGB)

Re: [Gimp-developer] color management

2004-07-12 Thread Sven Neumann
Hi, Øyvind Kolås [EMAIL PROTECTED] writes: new image parasite_set (export_profile, sRGB) loading of file profile==sRGB best scenario, just load the file parasite_set (export_profile,sRGB) loading of file !profile no color profile associated with image convert from [sRGB

Re: [Gimp-developer] color management

2004-07-12 Thread Øyvind Kolås
On 12 Jul 2004 21:47:21 +0200, Sven Neumann [EMAIL PROTECTED] wrote: loading of file !profile no color profile associated with image convert from [sRGB (dropdown)] save as [sRGB (dropdown)] parasite_set (export_profile, users_choice) This means that we would need to open a

Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: I don't know what the solution is. Maybe some way to (temporarily) associate an invokation of the colour selector with a specific image? An entry in the Image menu Select colour in image's colour space? The color selector is opened from the toolbox

Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: Assume GIMP uses Sven's original idea (i.e. Alastair's preferred method) where images keep their original colour space. Say a user is working on an image in some colour space with a much larger gamut than sRGB. If the colour selector allows only

Re: [Gimp-developer] color management

2004-07-09 Thread Dave Neary
Hi, Quoting Sven Neumann [EMAIL PROTECTED]: All we are discussing here is whether it makes sense to use display filters to color-correct the image display (and optionally color selector displays). I don't think there is any argument about that. It does make sense to apply the monitor's

Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi, Dave Neary [EMAIL PROTECTED] writes: point that we are discussing is how file plug-ins should handle embedded color profiles, i.e. whether to attach the profile to the image or not. I may be listening to a different conversation. The other point was whether embedded profiles should

Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi David, David Neary wrote: I'll conduct some tests some time and try and figure out just how bad these quantisation errors could be. Great - quantitative data will really help. I've done some testing - I wrote a little program that puts every possible 8-bit RGB colour through an lcms

Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi Sven, Sven Neumann wrote: Well, it got to be doable in the file plug-ins since we don't want to have the core depend on lcms. Applying the embedded profile at load time could very well happen in the file plug-ins though. If the core needs to perform colorspace transformations then we should

Re: [Gimp-developer] color management

2004-07-09 Thread David Neary
Hi Alastair, Alastair M. Robinson wrote: Given the limitations we're trying to work within, I think the best compromise is likely to be something like this: snip some very good suggestions - Change the GIMP's working profile to match this image. This will leave the image data

Re: [Gimp-developer] color management

2004-07-09 Thread Sven Neumann
Hi, David Neary [EMAIL PROTECTED] writes: So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is

Re: [Gimp-developer] color management

2004-07-09 Thread David Neary
Hi, Sven Neumann wrote: David Neary [EMAIL PROTECTED] writes: 1) We stop using the profile for the first image (and if the image window is open, this will obviously change the visual representation of the image), but keep it attached to the image so that we can re-save it with the image

Re: [Gimp-developer] color management

2004-07-09 Thread Alastair M. Robinson
Hi Dave, David Neary wrote: So say I open an image with a color profile, and then load a second image with a different profile. If I now decide to do the above, what do we do to the first image? 1) We stop using the profile for the first image (and if the image window is open, this will obviously

Re: [Gimp-developer] color management

2004-07-09 Thread William Skaggs
It really isn't all that complicated. Here is all you need to do (this is basically what Sven outlined with a couple of extra details.) 1) Gimp uses the same color space internally for all images. This could be either sRGB or a user-selected one (in which case it is specified by a

Re: [Gimp-developer] color management

2004-07-08 Thread Dave Neary
Hi Alastair, I'm no colourspace expert (far from it), but there were a couple of things which I spotted in this which prompted questions. Quoting Alastair M. Robinson [EMAIL PROTECTED]: In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: There are as I understand it, two possible ways of dealing with colour profiles. In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded, scanned or whatever, it is

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Wed, 7 Jul 2004, Alastair M. Robinson wrote: Sven Neumann wrote: Well, we have only one internal color space. We just need to agree on what we want to call it... In the first method, is what I believe is what PhotoShop uses (and what I think Sven proposed): When an image is loaded,

Re: [Gimp-developer] color management

2004-07-08 Thread Jean-Christophe Dubacq
On Thu, Jul 08, 2004 at 05:47:56PM +0300, Steve Stavropoulos wrote: As for the proposed conversion on save to the starting colorspace, I completely dissagree. I don't see any reason to introduce more errors coming from a less than optimal conversion. What I think best is: Image (Any space)

Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs
Alastair M. Robinson wrote: In short, though, if we use this method, we don't need to agree on what to call our working space, because it will simply be whatever is appropriate for the image being edited! Dave Neary wrote: I think this is probably a very bad idea. I agree with Dave on

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Jean-Christophe Dubacq wrote: But one could want to make operations using specific profiles. I mean, addition is clearly not the same in CMYK or in sRGB, and marginally different in other color spaces. Gimp uses only one internal colorspace, 8bit RGB and I don't see that

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, William Skaggs [EMAIL PROTECTED] writes: I agree with Dave on this one. Here is just one example of the sort of nasty thing that can happen if different images use different color spaces, with corresponding display filters: You could have two two-layer images, A and B, such that:

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Sven, Sven Neumann wrote: This is also what I originally proposed at GIMPCon. I have then been told that this would be the wrong thing to do and that we should convert the image on load. Now that you backed up my original proposal I tend to agree with you that converting the image data is not

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Dave, Dave Neary wrote: Yes, this is what was discussed at the conference, with one important difference. We don't convert back to AdobeRGB or whatever at save time, we simply save the working image data, with the sRGB color profile. OK - I agree that converting back to the original space is in

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve, Steve Stavropoulos wrote: Whatever you do, you will have to make a compromise. The question is, There we are in full agreement :) You are worried about quantization errors during the conversion, but if you do the conversion in 16 bit or more I think you will not have much problems.

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi William, William Skaggs wrote: (1) Layer A1 is visually identical to layer B1. (2) Layer A2 is visually identical to layer B2. (3) When layers 1 and 2 are composited in Add mode, the two images look different. This can happen because of the nonlinearity in color profiles. I can see that this

Re: [Gimp-developer] color management

2004-07-08 Thread William Skaggs
Alastair M. Robinson writes: I beg to differ! A silently applied destructive change to the image data is in my opinion a very important factor! It should definitely not be silently applied. When you open an image that uses a different colorspace from the standard one, you should get a

Re: [Gimp-developer] color management

2004-07-08 Thread David Neary
Hi Alastair, Alastair M. Robinson wrote: Dave Neary wrote: Assuming we're using lcms, the internal conversion will be applied in full precision - the problem is that the destination data, by necessity of the GIMP's current limitations, must be 8-bit RGB. Converting 8-bit RGB data from

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi, David Neary wrote: I may be misunderstanding things, but if the conversion from the source colourspace to sRGB is done in lcms losslessly, then all we're losing is the out-of-gamut colours from the colourspace conversion. And, of course, the cost of discarding precision in the data we get

Re: [Gimp-developer] color management

2004-07-08 Thread Sven Neumann
Hi, Alastair M. Robinson [EMAIL PROTECTED] writes: The colour selectors are perhaps one of the trickier aspects of my proposal; for their RGB values to be meaningful, the transform applied to the colour selector would need to change to reflect the current image's profile. I am afraid that

Re: [Gimp-developer] color management

2004-07-08 Thread Steve Stavropoulos
On Thu, 8 Jul 2004, Alastair M. Robinson wrote: I'm not worried about the conversion so much as the fact that the limited precision of the destination data (8-bit RGB) will cause us to lose colour information. A conversion of 8-bit data between two RGB profiles will not be a 1:1 mapping, so

Re: [Gimp-developer] color management

2004-07-08 Thread Alastair M. Robinson
Hi Steve, Steve Stavropoulos wrote: That's exactly why we need the internal 8bit RGB colorspace used by gimp to be the widest possible. If the internal colorspace is wide enough then you won't notice any lost colors during the conversion. I don't know how I'm not actually talking about gamut

Re: [Gimp-developer] color management

2004-07-08 Thread Tor Lillqvist
I am afraid that this is not possible simply because the color selector is not associated with an image. All we can do is to correct the color selector using the monitor profile. You mean that the colour selector would implicitly always be sRGB? I'm afraid that's not a good idea. Assume

Re: [Gimp-developer] color management

2004-07-07 Thread Alastair M. Robinson
Hi, (Second try, this time sent to the list at large. Brains where art thou!) Sven Neumann wrote: Well, we have only one internal color space. We just need to agree on what we want to call it... My two-penneth (as author of the separate plugin, and a day-to-day user of the GIMP in a pre-press

Re: [Gimp-developer] color management

2004-07-06 Thread Sven Neumann
Hi, Tor Lillqvist [EMAIL PROTECTED] writes: Er, what's linear about sRGB? It's gamma encoded (and that's a good thing). Doesn't the term linear in the context of colour spaces mean one with components that are linear in intensity, i.e. a linear transformation of the CIEXYZ colour space,

[Gimp-developer] color management

2004-07-05 Thread Sven Neumann
Hi, one of the things we dicussed shortly at GIMPCon was how to add basic color management to GIMP. We know that it will be a major effort to integrate this and it will need GEGL to do it properly. However there are a few things in this area that we should be able to do for GIMP 2.2. That should

[Gimp-developer] color management

2004-07-05 Thread Tor Lillqvist
Sven Neumann writes: When an image file we open has an embedded color profile we should ask the user if the image should be converted to linear sRGB (which is what GIMP assumes internally). Er, what's linear about sRGB? It's gamma encoded (and that's a good thing). Doesn't the term linear

  1   2   >