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! 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