[
https://issues.apache.org/jira/browse/PDFBOX-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13163798#comment-13163798
]
Andreas Lehmkühler commented on PDFBOX-1185:
--------------------------------------------
Can you please attach the pdf in question?
> 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
