[Openicc] cups-filters

[James Cloos]

>>>>> "TK" == Till Kamppeter <till.kamppeter at gmail.com> writes:

JC>> Embed an icc profile and use ICCBased (scn, SCN, sh, Bl, Do).

TK> What does "(scn, SCN, sh, Bl, Do)" mean?

Those are the commands used in the pdf when using ICCBased color.
Cf PDFReference17.pdf p238. (§4.5.2).

TK> Probably cups-filters will then have to depend on this, so that not each
TK> and every package brings the same profiles into the system. Am I right?

I believe so.

>> You may need to create an icc for sGray.  GS has one, but unlike their
>> sGray PostScript colorspace definition, their sgray icc is a simple
>> gamma 1.8 space.  The sgray profile in graphicsmagick does the same.
>> 

TK> How does one create such a profile?

There is some good code in the colord source (client/cd-create-profile.c,
cd_util_build_srgb_gamma() and cd_util_create_standard_space()).

I think I see how to do it using srgb.icc, iccToXml and xmlToIcc.  I'll
test my hypothesis and post the results if they work.

TK> I checked Endianess now. my PWG Raster input files are all "Ras2" as
TK> required by the PWG Raster spec (does this implicitly require PWG Raster
TK> to be Big Endian?).

I'd forgotten that detail.  Yes, pwg raster IS big-endian only.

TK> These files give broken PDF output: Images are completely scrambled,
TK> look like random pixels or white noise, text and drawing areas are
TK> correct structure but wrong colors.

The 16bit rgb raster values should be 0x0000.RRRR.GGGG.BBBB for each pixel.

PDF rgb, when 16bpc, would be 48bit per pixel, rather than pwg's 64.
It looks like you are writing the high bits, unless cupsRasterReadPixels()
drops them?

Hmmm. ... ... ...

It looks like cupsRasterReadPixels() auto-converts the pixels into
native bit order.  You'll have to undo that with htons(3).

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 0x997A9F17ED7DAEA6