|
»
»
« Return to Thread: Re: lgm talk, part 2
Re: lgm talk, part 2
by Andrew A. Gill
::
Rate this Message:
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
>
> 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
« Return to Thread: Re: lgm talk, part 2
| Free embeddable forum powered by Nabble | Forum Help |
