can not view JBig2 image

[Charltsing]

look at this

if (usesJbig2)
        {
            // Direct GetPixmap() on some FreePic2Pdf JBIG2 scans can yield black images.
            // ConvertToPdf rewraps content into a new PDF that MuPDF can render reliably.
            byte[] pdfBytes = doc.Convert2Pdf();
            using var conv = new Document("pdf", pdfBytes);
            using var convPage = conv[0];
            pix = convPage.GetPixmap();
        }

[GitHubRulesOK]

Same as many other formats the JpX/big/2000 range is a poor choice for imagery especially in PDF which was designed with non-alpha basic JPEG or Fax TIFF as the native image formats in the 1990s. So, no support for PNG or GIF or others they had to be converted to be roughly PBM(ish) first.

The code for jpeg extensions was clouded by licensing, and only now over a decade later, is open JXL (2015=FLIF= Free Universal Image Format) still being considered for PDF standard Version 2.x

MuPDF uses the ArtiFex source library used by many JBig2 decoders but it could not be expected to cover all variations and apparently Patents for JBIG2 are owned by IBM and Mitsubishi. Many countries suggest it NOT be used for Archiving as lossy has known problems. The Software used to compact (Impact) the format uses it to agressively reduce image size but at the cost of compatability outside Acrobat such that it works in those Edge versions with the upsell Adobe viewer but not those without upsell.

[Charltsing]

ArtifexSoftware -> jbig2dec support this jbig2 data

[GitHubRulesOK]

I have tried your test file in over a dozen and more PDF viewers and handlers and the only one that can modify those images to view them is Adobe (Acrobat in Edge) The only closest relative I have not tested is Foxit Editor which might work as more Chinese than most.
I have seen the images in a very old viewer but not while they were inside the PDF only outside it and cannot be converted unless you use an image printer to print as an image such as tif Thus the best suggestion is print from Acrobat into a normal image.

[GitHubRulesOK]

here Is one I wrote by hand it is all about the jbig proposal so the source then was 4KB but as modern jBIG2 is 23 KB

lossless-jbig2.pdf

Here is yours rebuilt without the disruptive format so a bit bigger as 134,968 bytes rather than 134,770 bytes because I did not compress the xref etc.

muTest.pdf

The main difference is the removal of the heder before the data

[Charltsing]

This PDF cannot be viewed using readers that utilize PDFium or MuPDF.

It’s difficult for me to explain to users why Adobe Acrobat Reader can open this , while other readers cannot.

[GitHubRulesOK]

A RAW image file when used in a PDF may have small changes at start and finish to be compatible with PDF usage this not just true of JBig but is more noticeable such that jBig encoders have an option to make the jBig stream compatible with PDF.

I wrote your images using a single exe img2pdf which correctly alters the header to remove the incorrect starter bytes.
In hex terms the acceptable start is /Length 15057

6D 0A 00 00 00 00 30 00 01 00 00 00 13 00 00 07 08 00 00 0A 68 00 00 00 60 00 00 00 60 01 00 00 
00 00 00 01 26 00 01 00 00 3A A8 00 00 07 08 00 00 0A 68 00 00 00 00 00 00 00 00 00 08 03 FF FD

the incorrect one is /Length 15092 so it is not seen here as simple as just truncate the header bytes,
so other parts need conversion too

97 4A 42 32 0D 0A 1A 0A 01 00 00
00 01 00 00 00 00 30 00 01 00 00 00 13 00 00 07 08 00 00 0A 68 00 00 00 60 00 00 00 60 01 00 00 
00 00 00 01 26 00 01 00 00 3A A8 00 00 07 08 00 00 0A 68 00 00 00 00 00 00 00 00 00 08 03 FF FD

[GitHubRulesOK]

The answer is Adobe Acrobat allow many things that dont match its specification as Openly licensed.
So same as docX if the file has MS contructs ONLY Word can internally edit the structure and with PDF if it is edited by Adobe Readers nobody else can do exactly the same.

You need to use a PDF writer that writes the PDF file in the common format non Adobe PDF readers expect it. here seen in comparison MuPDF base in center and PDFium either side the one on the left is yours the one in the middle on the right is standard

This is a comparison of ONE jBIG encoder that has non-pdf and std-pdf outputs we can see the PDF version is smaller there are 13 bytes less at the start and at the end it is 22 bytes smaller.

compare the file sizes

non-pdf.jb2 21692 bytes
std-pdf.jb2 21657 bytes
difference     35 bytes

The 22 bytes are NOT the problem all I need to do is delete the 13 bytes at start of each image and it is pdf compatible.

[GitHubRulesOK]

OK wrote a fixer it simply strips the bad -JB2 data so not perfect but simple However you must clean the pdf as xref and other parts will have been affected so the CMD file is at https://github.com/GitHubRulesOK/SumatraPDF-Plus/blob/master/Plus/StripJB2.cmd

easiest way to use it is drop a file on the CMD

With .net

[GitHubRulesOK]

@kjk this is simply a non standard use of JB2 data in an Adobe filter that Adobe handle differently "in-house"
Nobody else seems to accept the poor data, not even those that read JB2 native raw files.

the key point is MuPDF (and everyone else) rightly expected a headless (JB2.PDF) stream see https://github.com/ArtifexSoftware/mupdf/blob/c9ee2ee481a617d7543137a10e2076648801358e/source/pdf/pdf-stream.c#L194

But they are now accepting those external JB2/JBIG2 formats with native headers (similar to Acrobat) so is in 3 recent commits However mutool clean at present does not convert them you would need to use the inferior mutool draw or write a JScipt here is the result of mudraw