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
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 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
20 matches
Mail list logo
