Re: lgm talk, part 2

[Guillermo Espertino]

> It seems to me you completely misunderstood the whole thing. What makes
> you think there is any CMYK -> RGB conversion involved here?

I think he's talking about the procedure to perform when the source file
is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
files" section of the Peter's document).

I have to say that after reading the whole proposal I'm pretty
enthusiastic about these changes (even though I wasn't very convinced at
first).
It looks like a totally different way to manage the workflow and it
lools very promising.
However, the "what about CMYK files" sounds destructive, since the
original separations will be discarded and a new separation will be
created.
The projections thing sounds great for new artwork, where you can
actually define what layer will go in each plate, but sounds tricky for
flattened artwork.
What if I want to touch up an image that a client sent me, already
separated?

Gez

_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Martin Nordholts-2]

Guillermo Espertino wrote:
>> It seems to me you completely misunderstood the whole thing. What makes
>> you think there is any CMYK -> RGB conversion involved here?
>>    
> I think he's talking about the procedure to perform when the source file
> is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
> files" section of the Peter's document).
>  

To me it sounded as if he thought there would be constant lossy RGB ->
CMYK -> RGB conversions when you do adjustments after having pulled down
the CMYK projection, but the adjustment you do with the CMYK projection
is already is in the CMYK space, they just get reapplied all the time
(this is where the non-destructiveness comes in). The edits you do in
RGB is a one way transform only to CMYK, so there is no destructive RGB
-> CMYK -> RGB -> CMYK -> RGB -> CMYK involved here either.

Anyway, I apologize if I misinterpreted you Andrew.

BR,
Martin
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrew A. Gill]

On Sat, 20 Jun 2009, Martin Nordholts wrote:
>
> To me it sounded as if he thought there would be constant lossy RGB ->
> CMYK -> RGB conversions when you do adjustments after having pulled down
> the CMYK projection, but the adjustment you do with the CMYK projection
> is already is in the CMYK space, they just get reapplied all the time
> (this is where the non-destructiveness comes in). The edits you do in
> RGB is a one way transform only to CMYK, so there is no destructive RGB
> -> CMYK -> RGB -> CMYK -> RGB -> CMYK involved here either.

Conversion from RGB to CMYK with any sort of color management is
inherently lossy.  RGB is a ginormous gamut, capable of
expressing 16.8 million colors at 8 bits per channel.
Theoretically, CMYK should be able to express 4 Gi-colors, but in
practice, it is only able to express a fraction of them.

Many CMYK colors (I'm thinking rich blacks, but there may be
others) are identical to the human eye, and only become important
when you are looking at what colors are next to them.

I'm presently working with an imagesetter that outputs at 2540
dpi.  Assuming that I use a linescreen of 127 lpi (150 lpi is a
pretty common low-resolution setting), and assuming that I use
symmetrical halftone dots, and figuring in an ink limit of around
250% (normal for plain paper) I'm lucky to get 50 shades of gray
per color--giving me around 6 million colors total.

I don't know enough about CMS to know if it would work to have a
fake gamut for CMYK that would simply transform RGB losslessly.

What I do know is that if you intend to transfer any changes you
make in the press projection back to the RGB image, loss will
occur in those rich blacks.  I don't know if he's still
advocating that, but he seemed to be at one point.

--
| Andrew A. Gill     To ensure continued quality of service,   |
|                    this e-mail is being monitored by the NSA |
| <superluser@...> <http://www.needsfoodbadly.com> |
                                                               --
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[peter sikking]

I am gluing some posts together:

Guillermo Espertino wrote:

>> It seems to me you completely misunderstood the whole thing. What  
>> makes
>> you think there is any CMYK -> RGB conversion involved here?
>
> I think he's talking about the procedure to perform when the source  
> file
> is CMYK. The proposal is to convert it to RGB (in the "what about CMYK
> files" section of the Peter's document).
...
> What if I want to touch up an image that a client sent me, already
> separated?


OK, I see that I was not clear enough in my blog:

"When further fine‐tuning for the printing press is the goal,
  then the solution is to shove the CMYK file straight into a
  press projection, as a static, pre-defined separation. Each
  plate is then still fully editable as outlined before."

what i tried to say is that users will have a choice to _not_
convert a CMYK file to RGB, but to load it straight into a
press projection. the resulting file will have an empty RGB part,
and a static base separation that comes straight from the file.
I fully intent here that GIMP will be able to set up the press
projection from the file, including the number of plates, their
colors used and their order. maybe users will have to help with
saying that spot plate #2 uses pantone 1234 (say).

so now we have the CMYK file as lossless as it gets in to GIMP,
every plate can be touched up, or a block of text added..., or
all plates together get a curves applied for more oomph, or...

the result can be saved again to a separation file.

Hal V. Engel wrote:

>>> When a received CMYK file is to be used in new creative work, we  
>>> already
>>> saw that ‘it needs to be imported and converted to RGB.’
>
> And I am not sure that this is the correct approach.  Why would this  
> be
> needed?  Is this so that we can deal with GIMPs limited  
> functionality to
> handle anything beyond RGB color spaces?  If so then the focus  
> should be on
> supporting other color spaces directly.

I forgot to write in my blog that besides

"When a received CMYK file is to be used in new creative work,
  we already saw that ‘it needs to be imported and converted to  
RGB.’"

I see the whole process like taking a scanned image or an image from
a digital camera and include it in new creative work. similar to
those situations the MYK file import will need to be tuned up for
color balance and contrast before adding it to the creative work.

> I also have not any anything in the thread related to how color  
> management
> fits.   After all how do you create the printer specific separations  
> from an
> RGB (or other non-device specific) image into the correct device  
> values
> without involving the color management engine?

I did include that:

"Note also that the colors in the press projection are already
  slightly different than that of the normal view, because the
  color profile of the printing press is taken into account."

I am aware that color profiling is a very serious thing in
the world of printing presses.

     --ps

         founder + principal interaction architect
             man + machine interface works

         http://mmiworks.net/blog : on interaction architecture



_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer

[Andrew A. Gill]

On Sun, 21 Jun 2009, peter sikking wrote:

>
> OK, I see that I was not clear enough in my blog:
>
> "When further fine?tuning for the printing press is the goal,
>  then the solution is to shove the CMYK file straight into a
>  press projection, as a static, pre-defined separation. Each
>  plate is then still fully editable as outlined before."
>
> what i tried to say is that users will have a choice to _not_
> convert a CMYK file to RGB, but to load it straight into a
> press projection. the resulting file will have an empty RGB part,
> and a static base separation that comes straight from the file.
> I fully intent here that GIMP will be able to set up the press
> projection from the file, including the number of plates, their
> colors used and their order. maybe users will have to help with
> saying that spot plate #2 uses pantone 1234 (say).
>
> so now we have the CMYK file as lossless as it gets in to GIMP,
> every plate can be touched up, or a block of text added..., or
> all plates together get a curves applied for more oomph, or...
>
> the result can be saved again to a separation file.

OK.  I think you addressed my concern.

--
| Andrew A. Gill     To ensure continued quality of service,   |
|                    this e-mail is being monitored by the NSA |
| <superluser@...> <http://www.needsfoodbadly.com> |
                                                               --
_______________________________________________
Gimp-developer mailing list
Gimp-developer@...
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer