RE: 688177 Eliminate the 64 bit pixel size limit
"Dan Coby" <[email protected]> Fri, 2 Sep 2005 10:55:08 -0700
| Newsgroups | gmane.comp.printing.ghostscript.patches |
|---|---|
| Message-ID | <[email protected]> |
Ray, >So how does the 'overprint' compositor work with this? Overprint does work properly with this scheme. The overprint compositor already had logic for 'non separable' devices. It does execute slower. It is possible to add a special overprint compositor for this device but I am not sure about how large the performance improvement would be. >It seems that as pixels are painted over areas that are previously >painted, the compositing will need to allocate new colors. For example, >if a pixel was painted with 60%C, 5%M, 30%G and 100%"Varnish" when >painting with overprint with 100%"Die", then if I understand the >scheme the new color will be in a different index group with 5 >colorants instead of 4. Is that right? Yes. Typical examples of this are the files with a 'Varnish' overprinted over the entire page. If the file has more than seven colorants, then the new Varnish layer creates new component combinations with the added Varnish component. This does not happen with seven or fewer colorants since the component list is started with an entry that contains all seven colorants. >Second question, I think we can further optimize bits by having >indexes for 100% of a colorant that differ from 0 < colorant < 100%. There are possibilities with this idea. I did not do it for a couple of reasons: 1. The current implementation already works well with seven colorants and I think that this is already a very reasonable upper limit for the number of colorants that are likely to be in a single pixel. 2. It would make the implementation even more complex. Dan -----Original Message----- From: Ray Johnston [mailto:[email protected]] Sent: Friday, September 02, 2005 8:44 AM To: [email protected] Cc: Gs-Code-Review Subject: Re: [gs-code-review] 688177 Eliminate the 64 bit pixel size limit Dan, Thanks for the quick work on implementing this idea! Sorry for not responding sooner, but I've been sort of swamped with making sure I had what I needed from Ralph before he vacated. I had a couple of comments/questions: So how does the 'overprint' compositor work with this? It seems that as pixels are painted over areas that are previously painted, the compositing will need to allocate new colors. For example, if a pixel was painted with 60%C, 5%M, 30%G and 100%"Varnish" when painting with overprint with 100%"Die", then if I understand the scheme the new color will be in a different index group with 5 colorants instead of 4. Is that right? Second question, I think we can further optimize bits by having indexes for 100% of a colorant that differ from 0 < colorant < 100%. This would expand the colorants available since the index group would define 100% of that colorant, leaving the bits for the colorants that are no 100%. When painting with a range of a color, this would result in one index entry for the pixels that had 100% of that color and a different index entry for pixels that had less than 100%, but more than 0%, but since we often see 'real world' layers that are 100%, avoiding the need to reduce the bits per pixel seems to me to be worthwhile. If we do this, then we may want to handle CMYK without this since we will usually see each of these colorants at 100% as well as < 100% levels. Regards, Ray _____________________________________________________________________