Created attachment 190928 [details] sample PDF Steps: 1. Open attachment with the Draw or Writer filter. 2. Compare to other PDF readers and editors (tested Inkscape, Okular, Evince, Firefox, Foxit) Results: image colours are inverted. Applying the "Invert" image effect restores the original look. Reproduced in LO 4.0 as well as a recent master build: Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89) Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: baecfd21797310bb15ab98ca3962445d99e397db CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded
Noel/Patrick: thought you might be interested in this one.
Is this bisected to one of my commits?
(In reply to Noel Grandin from comment #2) > Is this bisected to one of my commits? No. Already bad since the filter was available, in libreoffice-3.4.0rc1 according to linux-64-releases bibisect repo.
Then sorry, I am not interested.
confirm with Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a91892ec4942fc875820ea02dfbe74e986548142 CPU threads: 4; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
I can reproduce this bug in my local build as well as in LibreOffice 7.5.8.2. Not sure if it helps, but I have located where in the code the embedded image is loaded into a SalBitmap. The image is a grayscale JPEG image 386x553 pixels in size that is copied directly into a SalBitmap with a 256 entry color palette. Frame #9 in the following stack snippet is where GraphicFilter::readJPEG() copies the loaded pixels to a SalBitmap. I am not familiar with parsing JPEG image files but my first guess is that LibreOffice's JPEG parsing code is setting the wrong grayscale palette: frame #9: 0x000000011590c15c libvcllo.dylib`GraphicFilter::readJPEG(rStream=0x0000600012206080, rGraphic=0x000000016fdf7710, rLinkType=0x000000016fdf7438, nImportFlags=SetLogsizeForJpeg) at graphicfilter.cxx:976:33 frame #10: 0x0000000115907ecc libvcllo.dylib`GraphicFilter::ImportGraphic(this=0x0000000116329338, rGraphic=0x000000016fdf7710, rPath="", rIStream=0x0000600012206080, nFormat=6, pDeterminedFormat=0x000000016fdf75d6, nImportFlags=NONE) at graphicfilter.cxx:1336:23 frame #11: 0x000000010f30c144 libsvxcorelo.dylib`(anonymous namespace)::SvXMLGraphicOutputStream::GetGraphic(this=0x000060001b40c180) at xmlgrhlp.cxx:295:43 frame #12: 0x000000010f30bf00 libsvxcorelo.dylib`SvXMLGraphicHelper::loadGraphicFromOutputStream(this=0x00000003710d2290, rxOutputStream=0x0000000129f68c98) at xmlgrhlp.cxx:612:46 frame #13: 0x000000011c3b7368 libxolo.dylib`SvXMLImport::loadGraphicFromBase64(this=0x0000000387238e50, rxOutputStream=0x0000000129f68c98) at xmlimp.cxx:1333:45 frame #14: 0x000000011c571a64 libxolo.dylib`SdXMLGraphicObjectShapeContext::endFastElement(this=0x0000000129f68ac0, nElement=328674) at ximpshap.cxx:2407:64
Note: the pdfium based 'insert as image' filter handles image correctly.
After some debugging, I no longer think that we are missing a custom grayscale palette in the embedded JPEG. Instead, my new theory is that LibreOffice is failing to read the /ColorSpace object for image. Specifically, in attachment https://bugs.documentfoundation.org/attachment.cgi?id=190928, object 23 (regex '^23 0') is the problematic JPEG image. It's colorspace is object 22 which contains a '/DeviceCMYK' that is defined in object 21. So I inverted the values in the object 21's '/Range' array. macOS Preview renders some random black pixels and LibreOffice renders the same. Not sure where to look next.