A problem with indexed color spaces: bpc of the base color space seems wrong.
-----------------------------------------------------------------------------
Key: PDFBOX-1185
URL: https://issues.apache.org/jira/browse/PDFBOX-1185
Project: PDFBox
Issue Type: Bug
Components: PDModel
Affects Versions: 1.7.0
Reporter: Antoni Mylka
Attachments: pdfbox-parentcsbpc.patch
I incorporated the "proper" solution to PDFBOX-1075 into my regression tests
and the file which made me raise that issue got broken again. It has pictures
with indexed color spaces, which now are returned as black. The indexed color
space is one-bit. The lookup table has two colors: black and white. With the
current trunk, the black pixels remain black (0,0,0), but the white pixels are
returned as (1,1,1), which in RGB is nearly just as black. The text on the
picture is obviously unreadable.
On a second look it seems to me that the offending line is here (in
PDPixelMap.getRGBImage):
{noformat}
ColorModel baseColorModel = csIndexed.getBaseColorSpace().createColorModel(bpc);
{noformat}
I think it's wrong, as in an indexed color space, "bpc" is not "bits per
component", but "bits per index" i.e. bits per the integer which is interpreted
as the index to the color lookup array. I think that the base color space's
color model should be initialized with a different number. I came up with a
following calculation:
{noformat}
PDIndexed csIndexed = (PDIndexed)colorspace;
PDColorSpace baseCs = csIndexed.getBaseColorSpace();
int numberOfColorValues = 1 << bpc;
int highValue = csIndexed.getHighValue();
int size = Math.min(numberOfColorValues-1, highValue);
byte[] index = csIndexed.getLookupData();
int parentComponentsCount = baseCs.getNumberOfComponents();
int baseColorModelBPC = (index.length * 8) / ((size+1) * parentComponentsCount);
ColorModel baseColorModel =
csIndexed.getBaseColorSpace().createColorModel(baseColorModelBPC);
{noformat}
The baseColorModelBPC is calculated as the total number of bits in the lookup
array divided by the total number of components in all colors. This seems to
work for my offending file and causes no regressions with files from
PDFBOX-1075, PDFBOX-1010 and PDFBOX-706.
What is weird though is a line which is later:
{noformat}
byte[] inData = new byte[baseColorModel.getNumComponents()];
{noformat}
Doesn't this effectively assume that baseColorModelBPC should always be 8? If
the base color model bpc were anything else than 8, then this code wouldn't be
able to handle it correctly anyway. Or am I overlooking something?
I'll attach a patch which works for me. Note that simply changing
{noformat}
ColorModel baseColorModel = csIndexed.getBaseColorSpace().createColorModel(bpc);
{noformat}
into
{noformat}
ColorModel baseColorModel = csIndexed.getBaseColorSpace().createColorModel(8);
{noformat}
has exactly the same effect (fixed my problem, no regressions in those three
earlier issues). Please decide what makes more sense.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
