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
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
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
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
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?
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.
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
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,
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
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
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
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
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
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
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
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
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
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
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
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:
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
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
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
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
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
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
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
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.
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
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
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
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,
--
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
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
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
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
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
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
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
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
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
] 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).
]
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.
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
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
___
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
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
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 -
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
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
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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)
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
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
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:
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
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
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.
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
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
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
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
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
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
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
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
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
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,
89 matches
Mail list logo