[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: The GIMP 2.0
From:       Paul Campbell <paul () taniwha ! com>
Date:       2004-01-15 16:13:04
Message-ID: 200401150813.04868.paul () taniwha ! com
[Download RAW message or body]

On Thursday 15 January 2004 07:44 am, James Richard Tyrer wrote:
> I must be totally missing your point.  I think that you are talking about
> the conversion from RGB to CMYK which is necessary to print.  I thought
> that I was clear that the linear model would have to be fudged there
> because the paper is not perfectly white and the inks are not perfect color
> filters.  The outdated methods that you describe to do this fudging may
> still be in use but there are now better ways to describe a non-linear
> function with data points.
>
> However when working with a color model for display on the screen you can
> assume that the paper is perfectly white and that the inks are perfect
> color filters.  Then the nonlinear functions that you are using table
> lookup for are not nonlinear and there is no need to use a table lookup
> with interpolation (or a more modern method such as cubic spline).
>
> We make the same assumption with RGB -- we assume that the phosphors on the
> tube are perfect (they are not).  The only issue that we have when using a
> model for the screen is that the color gamut is a cube.  But that doesn't
> effect the conversion.

I think I have 2 points, my main point is "it's not a simple as it seems" - in 
this thread people started out by quoting RGB->CMYK color space conversion 
forumulae from books ... there is no 1 right conversion.

The second point was something like "it's not possible to get perfect color 
matching between printer and screen, all you can hope for is 'good enough'".

Having said that I should respond somewhat to your comments - part of what I 
was talking about was CMYK->RGB (the inverse function - but in some sense 
easier because it's uaually a many to 1 operation rather than a 1 to many). 
Table lookup is important for speed if you are drawing in a CMYK space you 
have to do it on every pixel during paint animation operations and during 
window updates (I brought this up because many commercial users of tools like 
photoshop who work close to the print industry prefer to work in CMYK - for 
them it's more WYSIWYG - they also work day to day with CMYK color seps as 
proofs).

You can use curve fitting techniques to fit almost anything - my gut feel sais 
the things you need to do to model the wetting of different sized ink 
droplets on a 2-d surface and the resulting light absorbtion are not more 
inherently cubic than they are linear (actually I suspect they are probably 
linearish over most of their range and very non linear about the point where 
the droplets start to overlap and merge) - that's still something that is 
genuinely different on each type of press (and maybe every press and ink 
combination). On the other hand for color space conversion on output it's 
(more) OK to spend cycles doing fancy math because it's not an operation 
where the user is expecting instant update (in the same sense as pixel on the 
screen).

Finally the color gamut of a screen is not really a cube - gamma alone 
inflates the saturated portions (providing more codes for representing them) 
and squeezes the darker parts (provinding many fewer codes). This is 
particularly a problem if you start compressing images. A great (and sad) 
example of this can be seen in the digital video world where I now work - for 
historical reasons MPEG video is gamma corrected - there's no reason now days 
why this can't be done at the mpeg decoder rather than the studio, but they 
chose not to - this means that dark noir-like smoky sorts of scenes suffer 
badly from banding because there are too few dark colors to represent them - 
Blade Runner is my favorite example of something that suffers from this - 
sadly I expect movie directors mindfull of the DVD aftermarket will start to 
avoid this sort of scene. 

If you want to try and produce WYSIWYG color then you do have to model both 
the screen and the printer in some detail - you can produce a usefull result, 
better color matching,  but it will never be perfect.

	Paul
_______________________________________________
koffice-devel mailing list
koffice-devel@mail.kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]