Hätte es wirklich so einfach sein können, Xerox?

Ich bekomme Kommentare und Mails, die etwas sehr interessantes sagen. Kann es sein, dass im hier verwendeten JBIG2-Algorithmus direkt ein „Lossless“-Flag eingebaut ist, der den ganzen Mist hätte verhindern können, wenn man ihn nur angestellt hätte? Diese Pressemeldung sagt das zumindest (danke, Flavio). Money Quote:

supports traditional “lossless” compression, but also a new „lossy“ type of image compression, whereby the compression factor is increased on average by a factor of about 3 to 10, without noticeable visual differences compared with the lossless mode.

Die „lossy“-Variante ist das, was die Fehler hier verursacht. Das wichtige ist, wie der Auszug zu lesen ist. Der Faktor 3-10 bezieht sich auf die Lossy-Variante. Insgesamt heißt das, dass JBIG 2 wohl im lossless mode etwas kleinere Dokumente produziert als andere Kompressionsverfahren, und im lossymode noch mal massiv kleinere, aber u.U. auf Kosten der Datenintegrität.

Nach Angaben mehrerer Leser würde der lossless immer noch bessere Kompressionsergebnisse als andere Kompressionsalgorithmen liefern, und zusätzlich hätte man eine Garantie, dass die Daten auch tatsächlich von der Stelle des Blatts Papier kommen, die man erwartet! Dieser Modus soll eine einfache JBIG2-Einstellung sein, die der Programmierer (also Xerox) nur hätte treffen brauchen. Übersetzung für nicht-Programmierer: Das ist, wie wenn man einen Schalter umlegt, mehr nicht. (Danke, Nik!)

Ich will nicht unfair sein, ich kenne die exakte Implementierung von Xerox nicht. Wir wissen auch nicht, ob Nik sich vielleicht auf eine konkrete Implementierung bezieht. JBIG2 ist mehr ein Dekompressionsstandard als ein Kompressionsstandard. Vielleicht haben die den Losslessmodus nicht implementiert (was komisch wäre, zugegeben). Aber wenn diese Vermutung einiger Leser so richtig ist, ist natürlich die einzig wahre Frage: Warum hat Xerox das nicht gleich angeschaltet? Immerhin ist Datenintegrität ein extrem wichtiger Punkt! Der einzige für mich denkbare Grund wäre, aus Marketinggründen das letzte bisschen Dateigröße aus den Dateien herauszuprügeln. Das sieht ganz schön lächerlich aus in Zeiten, wo Speicherknappheit nicht mehr verbreitet ist, aber ein um den Faktor 3-10 besserer Kompressionsfaktor bietet natürlich neue Anwendungsmöglichkeiten, die sonst nicht möglich gewesen wären. Insgesamt: Nicht sicher, was damit jetzt anzufangen ist, aber ich finde es interessant genug um es euch nicht vorzuenthalten.

Edit: Fehler tritt angeblich auch bei anderen Kompressionen als "Normal" auf

Edit: Es kann sein, dass die Zahlenfehler auch auf anderen Kompressionseinstellungen als „normal“ auftreten! 8-O Ich finde das etwas zu krass um mich zu trauen, das jetzt selbst als bare Münze darzustellen, zumal ich beim Erstellen der PDFs ja auch nicht daneben stand.

Schaut mal mit drüber und seht es ausdrücklich noch nicht als wahr an! Natürlich habe ich Xerox informiert, ich will denen ja nichts böses, die waren ja auch freundlich zu mir. Schaut dieses PDF an, was ein Leser mir geschickt hat. Öffnet es mit einem Reader, der Kommentare lesen kann, wie z.B. Acrobat Reader, dann könnt ihr die Kommentare auf den Seiten sehen, welche Seite zu welcher Einstellung gehört. Es enthält auf der ersten Seite einen TIFF scan meiner Testzahlenreihen, und diverse andere Scans auf 300 DPI, und zwar über alle Einstellungen (normal, higher und high) hinweg, mit OCR an und aus. Angeblich wurde es auf einem WorkCentre 7655 gemacht. Guess what? ALLE Seiten enthalten falsche Zahlen. Wenn da jetzt nicht irgendwas anderes falschgelaufen ist, widerspricht das Xerox's Q&A-Dokument zu der Sache. Das sagt „You will not see a character substitution issue when scanning with the factory default settings.“ (aus Frage 6 in deren Dokument)„.

Edit2: Hier ist eine ähnlich erzeugte Datei von einem WorkCenter 5665, von demselben Leser. Wieder sind es verschieden eingestellte Scans derselben Seite in einem PDF, wieder kommentiert mit den jeweiligen Settings, und auch hier werden auch in anderen Modi als dem „normal“ 6en durch 8en ersetzt! Vorsicht, damit keine Verwirrung mit den Namen entsteht: Er hat die Einstellungen normal, high, and highest genannt. Das kann doch unmöglich die Wahrheit sein. Leute, mir ist das unheimlich. Ich informiere hier darüber, aber ich will ausdrücklich noch nicht behaupten, dass die auch in den Defaultsettings Nummern vertauschen, das soll bitte Xerox bestätigen, nicht ich. Bis jetzt gibt es noch keine Meinung dazu von Xerox.

Es scheinen also die Defaulteinstellungen betroffen, was Xerox doch ausdrücklich ausgeschlossen hat? What the heck? Ich kann das kaum glauben und hoffe das klärt sich noch auf. Als es nur eine betroffene Maschine war, hatte ich es noch einfach zu sagen, das ist bestimmt was mit kaputt was nicht der Fehler ist, aber bei zwei Maschinen …? Kann das jemand replizieren?

Edit3: Au weia… der nächste Leser sendet mir ein PDF von einem WorkCentre 7530 (er selbst meinte, es wäre ein 7535, aber das PDF sagt 7530). Er behauptet, er hätte das auf „High“ eingescannt, mit 300 DPI. Was man sieht, sind das ein paar Testzahlen in mehreren verschiedenen Schriftgrößen. Die vierte Zahl der linken Spalte enthält wieder eine 8 statt einer 6, die korrekten Werte stehen in den größer geschriebenen Spalten. Der Leser hat als PDF-Kommentar ein Kreuz neben die Zahl gemacht.

Da ich bis jetzt keine Rückmeldung von Xerox erhalten habe mache ich mich nun auf den Weg zu ein paar Xeroxgeräten und versuche, den Fehler selbst zu replizieren. Stand by.

:!: Ich weiß, ihr wartet. Ich bin im moment in engem Kontakt mit Xerox, bitte habt noch ein wenig Geduld. Wir versuchen ein paar Dinge rauszukriegen. Es tut sich was. Danke :-) :!:

Comments

Aufgrund von Caching kann es bis zu zwei Minuten dauern, bis ein Kommentar erscheint!

Da ich gerade ziemlich viel manuellen Spam aus Russland und Pakistan bekomme und keine Zeit habe, da wirksam gegen anzugehen, ist die Kommentarfunktion bis auf weiteres abgeschaltet. Wenn's pressiert, mailt mir!

Diesem Satz fehlt etwas: „Dieser Modus soll eine einfache JBIG2-Einstellung, die der Programmierer (also Xerox) nur hätte treffen brauchen.“

Ansonsten: Danke für die interessante Geschichte. ;)

1 |
nadar
| 2013/08/09 06:48 | reply

Da ich gerade unterwegs bin, ganz auf die Schnelle was zu der Datei 'wc5665test.pdf':

1. Die Metadaten der Datei weisen sie aus als auf einem 'Xerox WorkCentre 5665' erstellt, und zwar am Do, 8. August um 14:52:43 Uhr.

2. Alle Seiten sind im Letter-Format (792×612 pt).

3. Alle Seiten bestehen aus einem Rasterbild mit Farbtiefe 1.

4. Alle Seiten verwenden JBIG2-Kompression.

5. Alle Seiten liegen in einer Auflösung von 300dpi vor.

2 | | 2013/08/09 07:54 | reply

Hier die Metadaten. (Die Auflösungen habe ich berechnet.)

pdfinfo -f 1 -l 6 -meta wc5665test.pdf 

Creator:        Xerox WorkCentre 5665
Producer:       Xerox WorkCentre 5665
CreationDate:   Thu Aug  8 14:52:43 2013
ModDate:        Thu Aug  8 14:52:43 2013
Tagged:         yes
Form:           AcroForm
Pages:          6
Encrypted:      no
Page    1 size: 792 x 612 pts (letter)
Page    1 rot:  270
Page    2 size: 792 x 612 pts (letter)
Page    2 rot:  270
Page    3 size: 792 x 612 pts (letter)
Page    3 rot:  270
Page    4 size: 792 x 612 pts (letter)
Page    4 rot:  270
Page    5 size: 792 x 612 pts (letter)
Page    5 rot:  270
Page    6 size: 792 x 612 pts (letter)
Page    6 rot:  270
File size:      589999 bytes
Optimized:      yes
PDF version:    1.6
Metadata:
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="Adobe XMP Core 4.2.1-c043 52.372728, 2009/01/18-15:08:04        ">
   <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
      <rdf:Description rdf:about=""
            xmlns:xmp="http://ns.adobe.com/xap/1.0/">
         <xmp:ModifyDate>2013-08-08T14:52:43-04:00</xmp:ModifyDate>
         <xmp:CreateDate>2013-08-08T14:52:43-04:00</xmp:CreateDate>
         <xmp:MetadataDate>2013-08-08T14:52:43-04:00</xmp:MetadataDate>
         <xmp:CreatorTool>Xerox WorkCentre 5665</xmp:CreatorTool>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:dc="http://purl.org/dc/elements/1.1/">
         <dc:format>application/pdf</dc:format>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:xmpMM="http://ns.adobe.com/xap/1.0/mm/">
         <xmpMM:DocumentID>uuid:7b2372c8-28f6-4ed4-ab47-ed2b56c5931d</xmpMM:DocumentID>
         <xmpMM:InstanceID>uuid:dc071ad2-a635-4466-b088-12142e9c17d0</xmpMM:InstanceID>
      </rdf:Description>
      <rdf:Description rdf:about=""
            xmlns:pdf="http://ns.adobe.com/pdf/1.3/">
         <pdf:Producer>Xerox WorkCentre 5665</pdf:Producer>
      </rdf:Description>
   </rdf:RDF>
</x:xmpmeta>
3 | | 2013/08/09 08:01 | reply
pdfimages -list wc5665test.pdf 

page   num  type   width height color comp bpc  enc interp  object ID
---------------------------------------------------------------------
   1     0 mask     3296  2560  -       1   1  jbig2  no       117  0
   2     1 mask     3296  2560  -       1   1  jbig2  no         4  0
   3     2 mask     3296  2560  -       1   1  jbig2  no         9  0
   4     3 mask     3296  2560  -       1   1  jbig2  no        14  0
   5     4 mask     3296  2560  -       1   1  jbig2  no        19  0
   6     5 mask     3296  2560  -       1   1  jbig2  no        24  0
4 | | 2013/08/09 08:10 | reply

Hallo auch.

Ich hatte in meinem ersten oder zweiten Post geschrieben, dass wir bei zwei unterschiedlichen ColorCubes alles auf 300 dpi zu stehen hatten und der besagte Regler überall in der Mitte stand und trotzdem wurden Zahlen weiter ersetzt. Wir hatten den Regler auch nach ganz rechts bewegt - keine Änderung, weiterhin Ersetzungen. Erst später hatte ich die Optionen zum Deaktivieren des JBIG2-Algorithmus gefunden (separat für Mail-Scans und File-Scans). Ich hatte mir die Tatsache, dass der Regler keine Änderung auf JBIG2 hat so erklärt, dass wir nicht die aktuellste Firmware/Software-Version einsetzen.

Anstatt JBIG2 mit dem neuen Update ganz abzustellen, sollte man lieber die im obigen Text erwähnte lossy-Variante deaktivieren.

5 |
jm
| 2013/08/09 08:18 | reply

Danke, Nadar, Kurt und JM!

6 |
David Kriesel
| 2013/08/09 08:24 | reply

Abstellen von JBIG2 bei den ColorQubes:

9301:

Für File-Scans: Menüpunkt Scannen…Profil auswählen…ganz unten gibt es den Punkt Kompressionsfähigkeit.

Für Mail-Scans: Menüpunkt Einrichtung…E-Mail…Einrichten…Reiter Komprimierung

9201:

Für File-Scans: genauso wie beim 9301

Für Mail-Scans: Menüpunkt Einrichtung…Allgemeine Einstellungen…Bildeinstellungen

Kann natürlich sein, dass man eine andere Softwareversion, dann könnten die Menüpunkte woanders sein.

7 |
jm
| 2013/08/09 08:35 | reply

Den größten Effekt brachte übrigens die Verstellung des Kontrastes im Menüpunkt Bildverbesserung. Seltsamerweise war hier der Punkt manueller Kontrast eingestellt und der Regler stand in der Mitte. Nach dem Umstellen auf Auto-Kontrast sind die Zeichen-Ersetzungen an den beobachteten stellen trotz JBIG2 verschwunden. Wahrscheinlich wurde damit die Scanqualität deutch verbessert, so dass die Zeichen deutlicher wurden und JBIG2 keinen Mist gebaut hatte.

Es wurde durch den Fehler recht hektisch in den letzten Tagen und es wurde Einiges an den Geräten umgestellt. Also sollte man Kommentare, auch meine, mit Vorsicht genießen.

8 |
jm
| 2013/08/09 08:55 | reply

Ja, das mache ich auch, vielen dank dennoch … ich verwende sogar EXTREM wenig von dem was ich kriege … wenn ich hier alles auf die Seite knallen würde, was ich gerade reinkriege könnt ich ohnehin nichts anderes mehr machen … :-)

9 |
David Kriesel
| 2013/08/09 09:05 | reply

Die Datei zu dem WorkCenter 5665 machte den Eindruck, als ob sie „aus einem Guß“ gemacht sei und direkt von dem WorkCenter stammt. Die roten Kommentare sind natürlich nachträglich aufgebracht, die haben aber die Metadaten der PDF nicht geändert (dürfen sie auch nicht lt. PDF-Spezifikation).

Die Datei zu dem WorkCenter 7655 hingegen ist in jedem Fall nachträglich zusammengebaut (ist ja auch klar – die Aussage ist ja, dass die ursprüngliche TIFF als erste Seite eingebaut wurde).

Auf jeden Fall sieht die 7655er-Datei daher nicht aus wie 'aus einem Guss' und ihre Analyse ist etwas komplexer. Denn auf jeder Seite ab der 2. befindet sich noch ein weiteres Rasterbild mit JPEG-Kompression und rein weißer Farbe. Möglicherweise als Seiten-Hintergrund verwendet.

Was ich aber mit Sicherheit schonmal sagen kann:

1. Das Bild mit den Zahlen auf Seite 2 ist 2879×1782 Pixel groß und hat eine Auflösung von 300 ppi und verwendet JBIG2-Komprimierung. Es deckt nicht die komplette Seite ab, sondern nur den „Bildbereich“ (anders als bei der wc5665-Datei).

2. Fast dieselben Aussagen gelten für alle Bilder mit Zahlen auf den anderen Seiten 3-7 (außer den zuvor erwähnten Maskierungs-Bildern, die ja 'nix' enthalten) – mit dem Unterschied, dass dort die Pixelzahlen leicht abweichend sind: 2882×1783 (S.3 + S.4), 2882×1781 (S. 5), 2880×1783 (S. 6) und 2884×1781 (S. 7).

3. In der Datei ist von *erfolgreichem* OCR keine Spur zu finden (die Kommentare behaupten für die Seiten 4-7, dass dafür eine OCR eingeschaltet gewesen sei).

10 | | 2013/08/09 10:08 | reply