A Divendres 22 Agost 2008, Hal V. Engel va escriure: > On Thursday 07 August 2008 06:58:13 pm Leonard Rosenthol wrote: > > Correct. You'd need to make MAJOR changes to the rendering > > architecture of Poppler to do proper color management - especially > > where transparency is involved. > > > > But it would be a very good thing... > > > > Leonard > > (This is kind of long please bear with me). > > I have been looking at the PDF spec. and at the poppler code. Leonard is > correct that the code in it's present form is not designed to support color > management and it will require major changes. > > Some exmples: > > The PDF spec calls for all CIE based colorspaces (Lab, calRGB, calCMYK and > ICCBased) to undergo the following transformations: > > original color space -> XYZ -> output color space > > This implies that there is clear separation between the first conversion > and the second conversion and that one set of routines can handle the > second conversion for all CIE based color transforms. > > It also implies that there is some way for calling applications to specifiy > a CIE based output color space such as an ICC profile and related > information (rendering intents, black point comp. and output channel > depth). This is currently not possible. > > The code as it exists only does a direct conversion to XYZ in one location > GfxLabColorSpace::getRGB() and then does a second conversion to an > arbitrary RGB** color space in the same function. None of the other CIE > based color space conversions produce an intermeadiate XYZ conversion and > of course there are no generic XYZ to output color space routines. > > The gray and cmyk code for Lab conversions uses the getRGB() function and > then does some kind of generic conversion using the RGB values. Since > these RGB values are in an arbitrary RGB** color space the conversion to > gray and CMYK is also arbitrary. > > CalGray does not do gamma compensation in getGray() as called for in the > PDF spec. In addition the CalGray functions only support 8 bit depth. > What happens if there is a 16bit/channel gray image in a PDF file or if a > user wants 16 bit/channel output for his/her printer? > > CalRGB passes RGB values directly through to the output and makes no > attempt to convert these into an intermeadiate XYZ color space or into the > actual output colorspace. It also does not apply a gamma correction to the > data as per the PDF spec. > > End examples: > > I don't think that I am pointing out anything new to most on this list. > When I first started to look at the code I was hoping that it would not be > too difficult to find the places where CM hooks could be put in place and > that perhaps I could spend a few days putting together a set of patches > that would provide a starting place. But it appears that the code needs > significant restructuring in order to even start doing the actaul color > management specific work. Fortunately the PDF specification has enough > detail that it should be possible for the poppler team to do much of the > restructuring work without too much involvement from someone with color > management expertise. > > Mostly what is needed is: > > 1. An API for applications to specify the output color space, rendering > intent, black point compensation and channel depth for a document. These > are needed to correctly setup the XYZ to output color space transform. > > 2. The CIE related code (calRGB, calGray, Lab and ICCBased) needs to be > restructured so that it has a clean division between producing the > intermeadeate XYZ values and the code that does the XYZ to output color > space conversion. See the diagram on pages 238 and 239 of the version 1.7 > PDF Reference. > > Initially the ICCBased code could be left alone and calRGB, calGray and Lab > would be setup to convert to XYZ but would still do the current simplistic > conversions to the output color space (IE. these would all look some what > like GfxLabColorSpace::getRGB() & friends) . > > Then the XYZ to output color space routines would be added and the calRGB, > calGray and Lab routines would call them to handle the output conversion in > a more correct way. It is at this point where the code would start making > use of a CMS like LCMS as well as the API that was created in #1. This > functionality is documented in the diagram on page 239 of the PDF version > 1.7 spec as "Conversion from CIE-based to device color space (not specified > by PDF)". > > 3. At this point setting up the ICCBased routines to create XYZ > intermeadiate results would be added. Once this is in place poppler would > have a functioning color managed system for all of the CIE based color > space types. > > I have not looked at the PDF specs for "Special color spaces" such as > Separation, DeviceN, Indexed and Pattern so I do not know what implications > there are for these in a color managed system. I have also not looked at > transparancy issues but I didn't see much in the spec that related to > ICCBased objects other than that it was nessassary to have to AtoB and BtoA > tables in the profiles to support this and that all blending must be either > in device space or in CIE space and that the spec advises that CIE is > prefered. > > Many of you are probably asking "Why should we give a rats behind about > this?" The reason I am looking at this is that the printing community is in > the process of converting from PostScript to PDF as the standard document > type for printing for *nix systems. Because of this they are in the > process of writing a new pdftoraster filter for CUPS as well as putting > together a PDF based "Common Printing Dialog" (this is a Google Summer of > Code project). I asked on the printing email lists about color management > in the new printing workflow. Specifcally did the new pdftoraster filter > have CM support? I didn't get an answer and so I found the code and had a > look. Guess what (most of you probably know this) it is using poppler and > as a result it does not support color management. > > Printing is an important piece of the infastructure in general and > particularly for anyone doing color critical work. It is currently badly > broken with respect to color managemnt and it appears that until poppler > has CM support or another similar library with CM support becomes available > it will remain broken. So now you know what the story is and why this is > important. > > I have color management expertise (I am the maintainer of LProf) and I have > connections to the open source color management community where there are > many others with CM expertise some of them with way more expertise than I > have. As a community we have been working with the printing community, > Xorg and the DE's trying to get the missing CM components in place. > > There has been major progress with color management on monitors and we now > have calibration and profiling software for these devices as well as > support in XOrg (with more on the way) and work is underway to extend this > to include better user tools in KDE and GNOME. We also have good open > source tools for profiling input devices like cameras and scanners and > these profiles are now well supported by things like XSane, UFRAW and other > software in this area. > > We also have high quality profiling software for output devices like > printers. One of the major things that is missing is a viable color managed > path for printing. That is I can create very high quality profiles for my > printers but using them with the existing printing tools is at best > difficult even for someone who really understands CM and nearly imposible > for a normal user. If the CUPS pdftoraster filter had CM support much of > the printing part of this would start falling in place and would become > accessable to a much wider audiance. So from the point of view of the CM > community poppler is now a very important piece of software.
Woa that was long, eh ;-? Summary from my side: I don't have knowledge and more important, i don't have time to work on Color Management support for poppler, and i think noone else of the people you can consider "poppler developers" has either, so if you could drag someone from the CM community to work on poppler I would be more than happy trying to help. Albert > > Hal > > PS For those interested this web page from the ICC has a link to a PDF file > from Adobe that demonstrates CM or a lack of CM as the case may be: > > http://www.color.org/version4html.xalter > > > **It looks like it might end up being sort of sRGB since it uses a matrix > conversion and then a gamma conversion that is too simple to give actual > sRGB results since sRGB has a compound gamma curve. _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
