That's going to be hard to track down without a testcase (and knowing exactly how those images are encoded).

Because what does that even mean: mostly everything should be sRGB. What were the other choices? CMYK?

Barring that, if you can pinpoint a few misbehaving images, I'd gladly take the output of identify -verbose on those ;).

Might also be helpful to check how it renders w/ MuPDF, both the latest version, and what we're using (1.13.0).

That's going to be hard to track down without a testcase (and knowing exactly how those images are encoded).

Because what does that even mean: mostly everything should be sRGB. What were the other choices? CMYK?

I wish I knew! All I know that DriveThruRPG offers two PDFs for download, one with _srgb appended to the filename.

Barring that, if you can pinpoint a few misbehaving images, I'd gladly take the output of identify -verbose on those ;).

Might also be helpful to check how it renders w/ MuPDF, both the latest version, and what we're using (1.13.0).

Huh. MuPDF 1.12.0 (which is what is installed on Ubuntu 18.04, if https://packages.ubuntu.com/bionic/mupdf is to be believed) fails to render the image at all.

It outputs

error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
error: Cannot convert between incompatible pixmaps
warning: Ignoring error during interpretation
mupdf: warning: Errors found on page. Page rendering may be incomplete.

In 1.13.0 (built from source) it renders perfectly, though… ❓

In 1.13.0 (built from source) it renders perfectly, though…

Aw, I was hoping it was just an upstream issue fixed in 1.14, for example. ;-)

Found a freely available PDF with that bug!

You can download a free sample from here: https://www.drivethrurpg.com/product/186813/The-One-Ring--Erebor--The-Lonely-Mountain

Sadly the full version of this is available only in the mystery _sRGB version :(

I guess I can give the latest muPDF a try!

EDIT: Trying the latest doesn't make any sense if it's fixed in 1.13.0, does it?

It seems like muPDF used to have problems with those files, though?

Does KOReader use OpenGL? Because I compiled MuPDF without, for reasons of laziness.

SDL tends to use OpenGL, so the desktop build does. But I'd say KOReader probably doesn't use SDLOpenGL in a sense relevant to what you're asking.

I only see the problem on some of the pages btw.

SDL tends to use OpenGL, so the desktop build does. But I'd say KOReader probably doesn't use SDL in a sense relevant to what you're asking.

Okay!

I only see the problem on some of the pages btw.

Oh yeah, sorry if that wasn't clear in my original bug report. It doesn't affect every page!

There seems to be an smask in there. Maybe it's related to the problem? I don't have Adobe Acrobat at home so I can't really properly investigate these PDFs easily — or perhaps I rather don't quite know the tools.

Which page(s) render inverted in that sample? (I don't have a color KOReader build on hand ;p).

Pages 1, 2 & 9.

And you don't need color to see the effect, pages 2 and 9 would be completely unreadable on e-ink ;)

Have you checked? The rendering codepath is essentially completely different, so in theory, it may or may not exhibit this behavior ;).

At a quick glance, I'm not seeing anything obviously wrong in the way those JPEGs are encoded (pulled 'em via pdfimages, from poppler).

So, perhaps some PDF-specific shenanigans? In which case, I'm going to be less than useful ;).

@NiLuJe Plus extracting the JPEGs with pdfimages works just fine. Almost certainly something related to the PDF (the smask being my primary suspicious candidate at a quick glance).

@Frenzie: Yep, that's what I just tried, no issues with the images standalone or in a CBZ (at least on eInk) ;).

Right, I meant the extracted JPEGs render fine, not that extracting them does (though that does too). :-P

Have you checked? The rendering codepath is essentially completely different, so in theory, it may or may not exhibit this behavior ;).

Yes, that's how I found the bug in the first place 😁

Workaround: Rewrite the PDF file with ghostscript.

gs -sOutputFile=output.pdf -sDEVICE=pdfwrite -dCompatibilityLevel=1.4 -dNOPAUSE -dBATCH -dAutoRotatePages=/None input.pdf

⚠️ WARNING: PostScript is a complete programming language, and (if what I read is true) ghostscript will execute whatever commands it is given! It could install a trojan or delete your hard drive!
Do not run this on PDFs from an untrusted source! If you have to do so, use a virtual machine!

(There is command line option to run only "safe" postscript, but apparently malware authors have found ways around this.)

Slight tangent: If you are doing this, and you want to display the resulting file only on an eink device, you may as well convert it to grayscale and reduce the filesize a bit, by adding -sColorConversionStrategy=Gray -dProcessColorModel=/DeviceGray to the ghostscript command line.

As an aside, that command produces this interesting notice:

   **** This file had errors that were repaired or ignored.
   **** The file was produced by: 
   **** >>>> Adobe PDF Library 9.0 / PDF PT 3.10 (pdf-tools.com) / PDF PT 3.10 (pdf-tools.com) <<<<
   **** Please notify the author of the software that produced this
   **** file that it does not conform to Adobe's published PDF
   **** specification.

   **** The rendered output from this file may be incorrect.

Also it lost half its weight despite containing the same images and rendering the same? (Setting aside the issue in KOReader's MuPDF.) Is it just slimmed down in fonts or is something more… suspicious… missing? I'll have to check another time.

That's only in the samples, not in the paid-for files! That must be caused by the watermark.

Just the warning or also the filesize? The "sample file" overlay (or whatever it said precisely) doesn't disappear with the GS treatment.

The warning, I didn't look at filesize too closely.

Do you have Night mode on? I have same bug on Android when viewing pdf. Turning it off fixes the inverted colors

No, I do not have Night Mode on.

The problem is that the colors of the background are inverted, but those of the text are not, meaning that the contrast between them is minimal, making the pages unreadable. Night mode inverts both, offering no solution.

Fixed in #6738.

PS You can still get the PDF from http://web.archive.org/web/20161109001051/https://www.drivethrurpg.com/product/186813/The-One-Ring--Erebor--The-Lonely-Mountain, but directly not from the location linked above.

I have an unfortunately not-freely-available PDF that reproduces this issue in 2022.02. Any way I can use this to help?

Thanks, but nothing further is needed. ^_^ The file I linked in #5422 (comment) suffices to reproduce the issue.

I have a PDf that is showing this behavior on a Kobo Sage. #6738 seems to be all about font handling, but I guess if mupdf is updated this will be fixed?

Yes, it will come eventually.

hi, any progress on this negative image thingy? :)

Sort of. More pieces are ready than before.

FYI, I am having this same problem on a Lenovo M10 android tablet. What's interesting is that some pdfs from LevelUp5e show this image inversion, but others do not. Specifically Monstrous Menagerie and Memories of Holdenshire are inverted, but the Adventurer's Guide and Trials and Treasures look fine. I will check if the samples on DriveThruRpg have the same issues.

Is there anything I can look at in these files which might identify what is different between them cause this?

Feel free to investigate, but it'll be fixed eventually (I know, I know, it's taking its sweet time) and a workaround is posted in #5422 (comment). So I'd try to make sure your motivation is primarily curiosity. Of course it's possible the fix is fairly simple to write or backport, in which case you're absolutely welcome to. ^_^