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
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,
On Sun, Feb 14, 2010 at 10:03 AM, Christopher Curtis wrote:
> On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz 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
On Sat, Feb 13, 2010 at 5:58 PM, Jon Cruz 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
> reworking, and
On Feb 13, 2010, at 12:08 AM, David Gowers wrote:
> I agree; GIMP windows should support color management for individual
> image windows according to these atoms, absolutely;
> What it would be of little use to do, is to support showing the SAME
> image in a single window spanning multiple monito
On Feb 13, 2010, at 2:39 AM, yahvuu wrote:
>
> In reality, the wall of monitors probably won't work like that as long
> as GIMP has to manage the windows' colors. As others have said, it is
> unreasonable to manage split windows at application level.
Well, personally I don't consider it unmanag
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 Saturday 13 February 2010 09:15:13 am Christopher Curtis wrote:
> On Sat, Feb 13, 2010 at 5:39 AM, yahvuu 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 Sat, Feb 13, 2010 at 5:39 AM, yahvuu 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 equivalent t
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
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
>
On Sat, Feb 13, 2010 at 5:22 PM, Jon Cruz 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 to the app
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, yahvuu wrote:
>>
>>> here are some diagrams depicting selected configurations for
>>> colormanagement:
>>> http://yahvuu.files.wordpress.com/2009/08/dataf
On 02/12/2010 10:12 PM, Christopher Curtis wrote:
> On Fri, Feb 12, 2010 at 11:55 AM, yahvuu 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
On Sat, Feb 13, 2010 at 8:59 AM, SHIRAKAWA Akira
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 picker/selectors
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 Fri, Feb 12, 2010 at 11:55 AM, yahvuu 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 "monitor profile
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 t
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
>>
>
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 in
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
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 h
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 s
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 a
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
On 1/16/07, Sven Neumann <[EMAIL PROTECTED]> wrote:
> 2.6 has an even minor version number so it's obviously a stable release
Obvious only to people who don't need to ask.
> series. It will most probably use GEGL at a few places internally, but [...]
> 2.6 is to finish some stuff that wasn't com
On Tue, Jan 16, 2007 at 10:53:49AM +0200, Alexander Rabtchevich wrote:
> It is located at [WINDOWS]\system32\spool\drivers\color\ at least on 2000+
>
Plese usa [WINDOWS] as
%SystemRoot%
as in
http://support.microsoft.com/kb/259852/en
Perhaps this could be useful too:
http://www.adobe.com/su
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 profil
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 selection dialog isn't finished yet. But it already
installs a shortcut to the systemwide profile folder
Hi,
On Tue, 2007-01-16 at 11:16 +0300, Alexandre Prokoudine 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?
2
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
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
___
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 manageme
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 pop
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 wil
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,
--
Alasta
On Mon, 2005-08-08 at 23:31 -0700, Hal V. Engel wrote:
>
> 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)
> Printe
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
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 foregrou
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
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
On Monday 03 January 2005 14:27, Sven Neumann wrote:
snip
>
> I don't think we rejected this part. IIRC we said that it should be
> optional and that we want to allow people to disable color management
> entirely. Anyway, whatever we decide to do is just a matter of user
> interface and doesn't
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 sa
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.
]> 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,
"[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
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 par
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 paras
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 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,
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?
>
>
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,
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
___
Gimp-develo
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 us
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 pa
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
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,
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
>
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 app
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 wou
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"
> "
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")
loa
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 prefere
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 c
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
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
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:
> - Change the GIMP's working profile to match this image. This will
> leave the image data untouched. (This should disable the
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 post
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 transform.
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 profi
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 p
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 on
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 menu "Select colour in image's colour space"?
The color selector is opened from the toolbo
> 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 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 cli
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,
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
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 after
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 fro
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 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
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. In
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 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
fe
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 tha
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 tha
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, 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 spa
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
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
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
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 envi
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 sp
97 matches
Mail list logo