A Divendres 12 Desembre 2008, Koji Otani va escriure: > Very sorry, I attached a wrong file to the previous mail. > I attached a correct file to this mail.
I've commited the patch as i didn't find anything bad at first sight, probably setupColorProfiles should be tweaked in the future to allow changing the display profile on the fly, but that's not a huge problem since none of our consumers uses that at the moment :D Albert > --------- > Koji Otani. > > From: Koji Otani <[email protected]> > Subject: Re: [poppler] Color Management > Date: Fri, 12 Dec 2008 14:16:40 +0900 (JST) > Message-ID: <[email protected]> > > sho> I'm Koji Otani. > sho> > sho> I found a mistake in my patch. > sho> (one #ifdef --> #if) > sho> So, in case not using CMS, compiling error occurs. > sho> > sho> I attached fixed patch. > sho> > sho> > sho> > sho> > sho> > sho> From: Koji Otani <[email protected]> > sho> Subject: Re: [poppler] Color Management > sho> Date: Thu, 27 Nov 2008 17:57:37 +0900 (JST) > sho> Message-ID: <[email protected]> > sho> > sho> sho> Hi, All > sho> sho> > sho> sho> I made a patch to add Color Management to poppler. > sho> sho> I attached it to this mail. > sho> sho> This patch is one for current source in the GIT repository. > sho> sho> > sho> sho> I'm not a CM expert. And this patch doesn't resolve all problems. > sho> sho> But, I hope to make some progress. > sho> sho> Please try this. > sho> sho> ------------ > sho> sho> Koji Otani. > sho> sho> > sho> sho> -------------- > sho> sho> This patch adds Color Management feature to polper: > sho> sho> (1) Handling ICCBasedColorSpace (both V2 and V4 profiles) > sho> sho> (2) Handling CalRGB and CalGray > sho> sho> > sho> sho> This doesn't handle Rendering Intent. > sho> sho> This always renders with relative colorimetric intent > (default in PDF). sho> sho> This doesn't handle transparency. > sho> sho> > sho> sho> This uses Little cms library, so when compiling this, lcms-devel > package is sho> sho> needed. if lcms-devel package is not installed, > disable this feature. sho> sho> > sho> sho> In default, ICCBased uses builin Standard RGB, > sho> sho> Lab, CalRGB and CalGray don't use profile. > sho> sho> If you want to use other profile, put profile file to > sho> sho> $HOME/.xpdf/ColorProfiles/display.icc > sho> sho> or > sho> sho> /usr/share/poppler/ColorProfiles/display.icc > sho> sho> This profile is used by ICCBased, Lab, CalRGB, CalGray. > sho> sho> You can also change display profile from your application. > sho> sho> Before calling PDFDoc::displayPage, call > sho> sho> GfxColorSpace::setDisplayProfileName > sho> sho> or > sho> sho> GfxColorSpace::setDisplayProfile > sho> sho> > sho> sho> static void setDisplayProfile(cmsHPROFILE displayProfileA) > sho> sho> set profile handle > sho> sho> static void setDisplayProfileName(GooString *name) > sho> sho> set profile file name > sho> sho> If file name started with '/', it is handled as absolute > path name. sho> sho> Otherwise, it is handled as relative path to > sho> sho> $HOME/.xpdf/ColorProfiles/ > sho> sho> and > sho> sho> /usr/share/poppler/ColorProfiles/ > sho> sho> ----------- > sho> sho> > sho> sho> > sho> sho> From: "Hal V. Engel" <[email protected]> > sho> sho> Subject: Re: [poppler] Color Management > sho> sho> Date: Thu, 21 Aug 2008 18:51:59 -0700 > sho> sho> Message-ID: <[email protected]> > sho> sho> > sho> sho> hvengel> On Thursday 07 August 2008 06:58:13 pm Leonard Rosenthol > wrote: sho> sho> hvengel> > Correct. You'd need to make MAJOR changes to > the rendering sho> sho> hvengel> > architecture of Poppler to do proper > color management - especially sho> sho> hvengel> > where transparency is > involved. > sho> sho> hvengel> > > sho> sho> hvengel> > But it would be a very good thing... > sho> sho> hvengel> > > sho> sho> hvengel> > Leonard > sho> sho> hvengel> > sho> sho> hvengel> (This is kind of long please bear with me). > sho> sho> hvengel> > sho> sho> hvengel> I have been looking at the PDF spec. and at the poppler > code. Leonard is sho> sho> hvengel> correct that the code in it's present > form is not designed to support color sho> sho> hvengel> management and it > will require major changes. > sho> sho> hvengel> > sho> sho> hvengel> Some exmples: > sho> sho> hvengel> > sho> sho> hvengel> The PDF spec calls for all CIE based colorspaces (Lab, > calRGB, calCMYK and sho> sho> hvengel> ICCBased) to undergo the following > transformations: sho> sho> hvengel> > sho> sho> hvengel> original color space -> XYZ -> output color space > sho> sho> hvengel> > sho> sho> hvengel> This implies that there is clear separation between the > first conversion and sho> sho> hvengel> the second conversion and that one > set of routines can handle the second sho> sho> hvengel> conversion for all > CIE based color transforms. > sho> sho> hvengel> > sho> sho> hvengel> It also implies that there is some way for calling > applications to specifiy a sho> sho> hvengel> CIE based output color space > such as an ICC profile and related information sho> sho> hvengel> > (rendering intents, black point comp. and output channel depth). This is > sho> sho> hvengel> currently not possible. > sho> sho> hvengel> > sho> sho> hvengel> The code as it exists only does a direct conversion to > XYZ in one location sho> sho> hvengel> GfxLabColorSpace::getRGB() and then > does a second conversion to an arbitrary sho> sho> hvengel> RGB** color > space in the same function. None of the other CIE based color sho> sho> > hvengel> space conversions produce an intermeadiate XYZ conversion and of > course there sho> sho> hvengel> are no generic XYZ to output color space > routines. sho> sho> hvengel> > sho> sho> hvengel> The gray and cmyk code for Lab conversions uses the > getRGB() function and then sho> sho> hvengel> does some kind of generic > conversion using the RGB values. Since these RGB sho> sho> hvengel> values > are in an arbitrary RGB** color space the conversion to gray and CMYK sho> > sho> hvengel> is also arbitrary. > sho> sho> hvengel> > sho> sho> hvengel> CalGray does not do gamma compensation in getGray() as > called for in the PDF sho> sho> hvengel> spec. In addition the CalGray > functions only support 8 bit depth. What sho> sho> hvengel> happens if > there is a 16bit/channel gray image in a PDF file or if a user sho> sho> > hvengel> wants 16 bit/channel output for his/her printer? sho> sho> > hvengel> > sho> sho> hvengel> CalRGB passes RGB values directly through to the output > and makes no attempt sho> sho> hvengel> to convert these into an > intermeadiate XYZ color space or into the actual sho> sho> hvengel> output > colorspace. It also does not apply a gamma correction to the data as sho> > sho> hvengel> per the PDF spec. > sho> sho> hvengel> > sho> sho> hvengel> End examples: > sho> sho> hvengel> > sho> sho> hvengel> I don't think that I am pointing out anything new to > most on this list. When sho> sho> hvengel> I first started to look at the > code I was hoping that it would not be too sho> sho> hvengel> difficult to > find the places where CM hooks could be put in place and that sho> sho> > hvengel> perhaps I could spend a few days putting together a set of patches > that would sho> sho> hvengel> provide a starting place. But it appears > that the code needs significant sho> sho> hvengel> restructuring in order > to even start doing the actaul color management sho> sho> hvengel> specific > work. Fortunately the PDF specification has enough detail that it sho> > sho> hvengel> should be possible for the poppler team to do much of the > restructuring work sho> sho> hvengel> without too much involvement from > someone with color management expertise. sho> sho> hvengel> > sho> sho> hvengel> Mostly what is needed is: > sho> sho> hvengel> > sho> sho> hvengel> 1. An API for applications to specify the output color > space, rendering sho> sho> hvengel> intent, black point compensation and > channel depth for a document. These are sho> sho> hvengel> needed to > correctly setup the XYZ to output color space transform. sho> sho> hvengel> > sho> sho> hvengel> 2. The CIE related code (calRGB, calGray, Lab and > ICCBased) needs to be sho> sho> hvengel> restructured so that it has a > clean division between producing the sho> sho> hvengel> intermeadeate XYZ > values and the code that does the XYZ to output color space sho> sho> > hvengel> conversion. See the diagram on pages 238 and 239 of the version > 1.7 PDF sho> sho> hvengel> Reference. > sho> sho> hvengel> > sho> sho> hvengel> Initially the ICCBased code could be left alone and > calRGB, calGray and Lab sho> sho> hvengel> would be setup to convert to XYZ > but would still do the current simplistic sho> sho> hvengel> conversions to > the output color space (IE. these would all look some what like sho> sho> > hvengel> GfxLabColorSpace::getRGB() & friends) . > sho> sho> hvengel> > sho> sho> hvengel> Then the XYZ to output color space routines would be > added and the calRGB, sho> sho> hvengel> calGray and Lab routines would > call them to handle the output conversion in a sho> sho> hvengel> more > correct way. It is at this point where the code would start making use > sho> sho> hvengel> of a CMS like LCMS as well as the API that was created > in #1. This sho> sho> hvengel> functionality is documented in the diagram > on page 239 of the PDF version 1.7 sho> sho> hvengel> spec as "Conversion > from CIE-based to device color space (not specified by sho> sho> hvengel> > PDF)". > sho> sho> hvengel> > sho> sho> hvengel> 3. At this point setting up the ICCBased routines to > create XYZ intermeadiate sho> sho> hvengel> results would be added. Once > this is in place poppler would have a sho> sho> hvengel> functioning color > managed system for all of the CIE based color space types. sho> sho> > hvengel> > sho> sho> hvengel> I have not looked at the PDF specs for "Special color > spaces" such as sho> sho> hvengel> Separation, DeviceN, Indexed and Pattern > so I do not know what implications sho> sho> hvengel> there are for these > in a color managed system. I have also not looked at sho> sho> hvengel> > transparancy issues but I didn't see much in the spec that related to > ICCBased sho> sho> hvengel> objects other than that it was nessassary to > have to AtoB and BtoA tables in sho> sho> hvengel> the profiles to support > this and that all blending must be either in device sho> sho> hvengel> > space or in CIE space and that the spec advises that CIE is prefered. sho> > sho> hvengel> > sho> sho> hvengel> Many of you are probably asking "Why should we give a > rats behind about this?" sho> sho> hvengel> The reason I am looking at this > is that the printing community is in the sho> sho> hvengel> process of > converting from PostScript to PDF as the standard document type for sho> > sho> hvengel> printing for *nix systems. Because of this they are in the > process of writing sho> sho> hvengel> a new pdftoraster filter for CUPS as > well as putting together a PDF based sho> sho> hvengel> "Common Printing > Dialog" (this is a Google Summer of Code project). I asked sho> sho> > hvengel> on the printing email lists about color management in the new > printing sho> sho> hvengel> workflow. Specifcally did the new pdftoraster > filter have CM support? I sho> sho> hvengel> didn't get an answer and so I > found the code and had a look. Guess what (most sho> sho> hvengel> of you > probably know this) it is using poppler and as a result it does not sho> > sho> hvengel> support color management. > sho> sho> hvengel> > sho> sho> hvengel> Printing is an important piece of the infastructure in > general and sho> sho> hvengel> particularly for anyone doing color critical > work. It is currently badly sho> sho> hvengel> broken with respect to > color managemnt and it appears that until poppler has sho> sho> hvengel> CM > support or another similar library with CM support becomes available it > sho> sho> hvengel> will remain broken. So now you know what the story is > and why this is sho> sho> hvengel> important. > sho> sho> hvengel> > sho> sho> hvengel> I have color management expertise (I am the maintainer > of LProf) and I have sho> sho> hvengel> connections to the open source > color management community where there are many sho> sho> hvengel> others > with CM expertise some of them with way more expertise than I have. As > sho> sho> hvengel> a community we have been working with the printing > community, Xorg and the sho> sho> hvengel> DE's trying to get the missing > CM components in place. sho> sho> hvengel> > sho> sho> hvengel> There has been major progress with color management on > monitors and we now sho> sho> hvengel> have calibration and profiling > software for these devices as well as support sho> sho> hvengel> in XOrg > (with more on the way) and work is underway to extend this to include sho> > sho> hvengel> better user tools in KDE and GNOME. We also have good open > source tools for sho> sho> hvengel> profiling input devices like cameras > and scanners and these profiles are now sho> sho> hvengel> well supported > by things like XSane, UFRAW and other software in this area. sho> sho> > hvengel> > sho> sho> hvengel> We also have high quality profiling software for output > devices like printers. sho> sho> hvengel> One of the major things that is > missing is a viable color managed path for sho> sho> hvengel> printing. > That is I can create very high quality profiles for my printers but sho> > sho> hvengel> using them with the existing printing tools is at best > difficult even for sho> sho> hvengel> someone who really understands CM and > nearly imposible for a normal user. If sho> sho> hvengel> the CUPS > pdftoraster filter had CM support much of the printing part of this sho> > sho> hvengel> would start falling in place and would become accessable to a > much wider sho> sho> hvengel> audiance. So from the point of view of the > CM community poppler is now a very sho> sho> hvengel> important piece of > software. > sho> sho> hvengel> > sho> sho> hvengel> Hal > sho> sho> hvengel> > sho> sho> hvengel> PS For those interested this web page from the ICC has a > link to a PDF file sho> sho> hvengel> from Adobe that demonstrates CM or a > lack of CM as the case may be: sho> sho> hvengel> > sho> sho> hvengel> http://www.color.org/version4html.xalter > sho> sho> hvengel> > sho> sho> hvengel> > sho> sho> hvengel> **It looks like it might end up being sort of sRGB since > it uses a matrix sho> sho> hvengel> conversion and then a gamma conversion > that is too simple to give actual sRGB sho> sho> hvengel> results since > sRGB has a compound gamma curve. > sho> sho> hvengel> _______________________________________________ poppler mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/poppler
