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

List:       koffice-devel
Subject:    Re: The GIMP 2.0
From:       James Richard Tyrer <tyrerj () acm ! org>
Date:       2004-01-16 13:32:49
Message-ID: 4007E801.5070002 () acm ! org
[Download RAW message or body]

Paul Campbell wrote:
> 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.

Well I guess that that is the problem.  Perhaps you haven't taken higher math either? :-)
  There is one and only one theoretical or ideal RGB to CMY conversion algorithm and only
one for CMY to CMYK.  This is the same algorithm that is used with fudge factors for
actual printing except that for the ideal case, there are no fudge factors.

> 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'".
> 
Well, it is and it isn't.  The main problem is that the color gamut of the screen and the
printed page are not the same and there is no 100% satisfactory solution to that part of
the problem.

> 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).

As I said elsewhere, there needs to be an RGB representation for the screen display,
because that is what is displayed on the screen.  There is no need to have CMYK values for
the screen since there is a one to one correspondence between RGB and CMYK when using the
ideal model.  What is needed is to be able to use either the additive or subtractive color
model for color mixing and layers.

> 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)

Math definition: Linear is a straight line.

So, if it were linear, you wouldn't be doing a table lookup with interpolation.

Cubic spline curves are just an interpolation method.  Using them does not mean that the
curve being approximated was cubic, but that a cubic approximation is close enough. And,
the cubic approximation of a straight line is still a straight line.

> - 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).

Yes, I understand that real printing with real ink on real paper is a problem which
requires slightly different fudge factors for each combination.  But this has nothing to
do with the ideal case which is what you have when there are no fudge factors.

> 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.
> 
> 
This is quite interesting but isn't what I was talking about which is the representation
of the color on the screen.  This is a cube.  The HSV model is not a cube, it is a cylinder.

I believe that the banding which you speak of *is* caused by the fact that the color gamut
of the screen is represented as a cube.  The problem with is, as you stated, that the
smaller the Value, the smaller the number of Saturation and Hue values which are available
resulting in banding in shadows.  The same thing occurs at the other end of the value
scale but it isn't as noticeable -- the maximum number of discrete H*S values occurs at a
Value of 50%.  That is the limitation of the color gamut being a cube.  If you use gamma
correction, then it is a distorted cube but the problem remains.

> 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.

Until they produce perfect paper and perfect ink, it will never be perfect.  And, it
appears that displays (projection displays) are approaching perfect faster than ink on 
paper is.

--
JRT

_______________________________________________
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]