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

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.

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

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.