9

I'm a JPEG novice, and I'm trying to decode a (possibly corrupted) JPEG (or rather, JFIF) file.

My image viewer program complains about an illegal 0xb9 marker.

The file does not have an SOF (Start Of Frame) marker, instead it has this APP1 segment

ff e1 00 0b 50 49 43 00 02 28 3c 01 00

followed by this segment with a 0xb9 marker:

ff b9 00 11 08 06 4c 04 d3 03 01 22 00 02 11 01 03 11 01

What am I looking at here?

EDIT

I have been asked about where the file came from. Here's the story:

About 20 years ago I bought a collection of magazines on CD-ROMs. The magazines can, however, only be read on old Windows computers, so I'm trying to find another way to read them - preferably one that works on my Linux computer. As far as I can tell, the magazine pages are stored as a lot of JFIF files that are simply concatenated together.

So to start with, I've extracted one of the JFIF files, and now I'm trying to find a way to view it.

EDIT 2

I've been asked to share a picture file. I'm not sure if I'm committing a copyright violation by doing so, so I'll remove the file again after a couple of days. Anyway, one of the problematic picture files may be downloaded from here:

https://www.dropbox.com/s/9da72gdri8c9xwp/f1000.jpg

I have no idea what the file contains except that it is probably a page from MAD Magazine.

The ff b9 segment looks very much like a SOF0 segement, and changing it to ff c0 (SOF0) makes the picture visible, but only as a collection of random pixels.

The APP1 segment mentioned above contains the string PIC, which is not part of any APP1 segement type that I'm aware of.

EDIT 3

Since this question has now been answered, I will remove the file from Dropbox in order to avoid any copyright issues. Thank you to all who contributed to this.

oz1cz
  • 5,504
  • 6
  • 38
  • 58
  • 1
    Your FFB9 marker looks a lot like an SOF marker. Something is obviously screwed up though. – user3344003 May 07 '19 at 19:09
  • Where did the JPEG (JFIF) file come from, if you don't mind my asking? – jamieguinan May 07 '19 at 19:12
  • @jamieguinan: That's a relevant question. I'll update my post with that information. – oz1cz May 07 '19 at 19:26
  • Maybe change every `ff b9` to `ff fe` and it see if your decoder skips those segments as comments. Or as @user3344003 hinted, translate them into sensible SOF segments. – jamieguinan May 07 '19 at 20:03
  • `ff fe` doesn't work because an SOF marker is still missing. I tried changing it to `ff c0` (SOF) and now a picture is displayed, but it's just random pixels. Perhaps modifying the record to look more SOF-like will help. I'll need to experiment with that. But are y'all saying that `ff b9` is not a legal marker? According to https://gitlab.gnome.org/GNOME/gdk-pixbuf/issues/70 I'm not the only one seeing that type of marker. – oz1cz May 07 '19 at 20:58
  • Would it be possible to share one such file? As we have only small parts of the puzzle, we can only guess.. Perhaps the marker is a SOF9 (`ff c9`)? Maybe a bit exotic for an old Windows magazine, but who knows... I'd just try all the possible SOFn variants, and see if anything works. – Harald K May 09 '19 at 09:52
  • 1
    @haraldK: I've edited my post to include a link to a file. – oz1cz May 09 '19 at 10:48
  • 2
    markers X’FF02’ through X’FFBF’ are reserved in ITU T.81. – DaBler May 10 '19 at 13:33
  • 1
    I tried opening your example image in GIMP after making the `FF B9` -> `FF C0` change, and got an error saying "Huffman table 0x00 was not defined". I assume whatever viewer you used just ignored that error and ended up outputting random garbage instead. (FWIW, I also tried [injecting the standard JPEG Huffman tables](https://stackoverflow.com/a/50243066) into the file, but all that got me was a bunch of RGB salad and a "Corrupt JPEG data: bad Huffman code" error halfway through the image.) – Ilmari Karonen May 11 '19 at 13:09
  • Number info: 0xb9: ASCII code for Superscript one if that helps https://numbermonk.com/hexadecimal/185/en –  May 14 '19 at 12:34
  • 3
    [Apparently](https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-T.86-201206-I!Amd1!PDF-E&type=items) the APP1/PIC segment contains "[Accusoft Pegasus](https://en.wikipedia.org/wiki/Accusoft) custom fields". Still not sure what the FFB9 segment is, although I did find [this source file](https://github.com/thorfdbg/libjpeg/blob/master/codestream/tables.cpp) that claims it might indicate "residual scan, ac coded" (whatever that actually means). – Ilmari Karonen May 14 '19 at 14:42
  • 1
    @IlmariKaronen: You nailed it! It is indeed an Accusoft Pegasus picture file. I downloaded a demo version of Accusoft's "Apollo" picture viewer, and it displayed the file beautifully. Now I only have to find a way to convert my thousands of Accusoft files to something useable. :-) If you would rephrase your comment as an answer to my question, I will acknowledge it as an answer and award you the bounty. – oz1cz May 15 '19 at 07:23
  • There is [another source file](https://github.com/thorfdbg/libjpeg/blob/master/codestream/acsequentialscan.cpp) that even appears to have an implementation for ffb9 (arithmetic coding, lossless or hdr encoded as residuals). Only it doesn't want to eat the attached file. Maybe the file is not quite standard or the library is buggy. –  May 15 '19 at 14:54
  • So actually your best bet to get this working on a Linux computer may be with [wine](https://www.winehq.org/). –  May 15 '19 at 16:32

1 Answers1

4

According to ITU T.86 Amendment 1, the APP1 segment with identifier "PIC" contains "Accusoft Pegasus custom fields." This suggests that the file may have been created using Accusoft tools, and that they might be able to decode it as well.

(Indeed, in your comment above you say that you managed to successfully open the file using the demo version of Accusoft's "Apollo" picture viewer.)

As for the FFB9 segment marker, I'm still not sure what it means. I did manage to find some code in the JPEG XT reference implementation (called "libjpeg"; not to be confused with the widely used library of the same name by the Independent JPEG Group) that appears to recognize it, and includes a comment saying that it denotes "residual scan, ac coded". Whatever that means, however, I'm not 100% sure about.

Apparently it has something to do with supporting images with more than 8 bits of dynamic range per pixel, with the "residual scan" storing additional high-precision pixel data which can be combined with the basic 8 bit JPEG image data to reconstruct the full HDR image. But if so, it seems strange to have a file with only such a residual scan marker without any normal SOI marker. Given that, according to jakub_d, the JPEG XT library cannot actually parse your file, it might be that it's using the marker in some nonstandard way.

Ilmari Karonen
  • 49,047
  • 9
  • 93
  • 153