[ https://issues.apache.org/jira/browse/PDFBOX-1185?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13167582#comment-13167582 ]
Antoni Mylka commented on PDFBOX-1185: -------------------------------------- Sorry I can't, it's confidential. I'll try to find a public one. > 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