Datum: 31.05.2005 Uhrzeit: 22:10:37 Frank Ledwon Heiko Kanzler wrote: >>> Bin eigentlich froh das RAW bei der Oly gar nicht komprimiert >>> wird und das SHQ Jpeg nur gering wie man an den 5mb erkennt. > > Ähem?! Gesundheit 😉 Die ORF-Dateien der E-300 enthalten übrigens *vor* und die SHQ-Dateien *nach* den Haupbilddaten ein großes, entwickeltes Jpeg-Bild (ca. 400KB) für die kameraintere Vorschau. Die 5MB großen SHQ-Dateien sind deshalb eigentlich nur 4,6MB groß 😉 Bei der E-10, der E-20 und der C-Serie gibt es in den ORF-Dateien keine eingebetteten Jpeg-Vorschaubilder, in der E-1 und der E-300 dagegen schon 😉 In den ORF-Dateien von E-1 und E-300 ist dafür immer ein gewisser Speicherplatz reserviert, da die Grö¶ße der Jpeg-Vorschaubilder ja auch vom Bildinhalt abhängig ist. Die Hauptbilddaten stehen trotzdem immer an der gleichen Stelle [3] in der ORF-Datei. > Das RAW-Bild IST doch (verlustfrei) komprimiert. Das scheint zwar auf den ersten Blick richtig zu sein, aber die Begründung > Das 13 MB Raw enthält knapp 22 MB Bilddaten… ist natürlich Lö¶tzinn 😉 Am besten ich hole mal etwas weiter aus, damit dieses Problem endlich mal ausführlicher abgehandelt wird. Die nachfolgenden Ausführungen betreffen ausschließlich ORF-Dateien. Rawbilder aus der E-10 haben eine fixe Grö¶ße von 7614592 Bytes. Die Grö¶ße des latenten Bildes ist 2256*1684 [1] mit 10bit Auflö¶sung [2] digitalisierter Sensordaten. Die ersten Sensordaten stehen laut den Metadaten [3] auf Offset 16384, davor befinden sich nur TIFF-Header und EXIF-Daten. Die 10bit-Werte werden mit Nullbits aufgefüllt und als 16bit-Wort (2 Bytes) gespeichert: 2256 * 1684 * 2 = 7598208 Bytes Rechnen wir noch die 16384 Bytes Metadaten hinzu: 7598208 + 16384 = 7614592 Bytes Tada und schon haben wir die Dateigrö¶ße der E-10-ORF-Datei. Bei der E-20 ist es ähnlich wie bei der E-10. Fixe Dateigrö¶ße: 9928832 Bytes. Latentes Bild: 2576*1924 mit 10bit Auflö¶sung. Gespeichert werden wiederum jeweils 16bit pro Sensorwert. Erste Adresse der Sensordaten ist ebenfalls 16384: 2576 * 1924 * 2 + 16384 = 9928832 Bytes Dann wenden wir uns als nächstes der C-Serie zu. Dort gibt es auch verschiedene Modelle, die Rawdaten als ORF-Datei speichern kö¶nnen. Im Gegensatz zur E-Serie (mit Kennung ‚OR‘) haben die ORF-Dateien der C-Serie die Kennung ‚SR‘. Der prinzipielle Unterschied zwischen diesen ORF-Dateien besteht ganz einfach darin, daß in der C-Serie die Zeilen halbbildweise gespeichert werden (1, 3, 5, .., 2, 4, 6, …). Die E-Serie speichert die Zeilen dagegen immer fortlaufend (1, 2, 3, ..). Deshalb macht die unterschiedliche Kennung im TIFF-Header durchaus Sinn 😉 Als Beispiel greifen wir uns mal die C-8080 heraus. Fixe Dateigrö¶ße: 12091780 Bytes. Latentes Bild: 3280*2453. 12bit Auflö¶sung. Erster Offset der Sensordaten 16672. Eine einfache Rechnung, basierend auf der Annahme die 12bit-Werte werden wieder als 16bit-Werte gespeichert, sieht dann so aus: 3280 * 2453 * 2 + 16672 = 16108452 Bytes Oops, das Bild passt ja überhaupt nicht in die Datei rein 😉 Eine weitere Rechnung setzt einfach die beiden Werte ins Verhältnis (zö¶ge man vorher jeweils noch die 16672 Bytes Metadaten ab, dann wäre das Ergebnis noch genauer): 12091780 / 16108452 = 0.75 Die Datei der C-Serie ist also 25% kleiner als eine vergleichbare Datei aus der E-10 der E-20 groß wäre. Wie kann das sein? Nun, das ist ganz einfach: Anstatt die 12bit Sensorwerte mit 4 Nullbits aufzufüllen und jeweils als 16bit-Wert zu speichern, werden in der C-Serie nur die tatsächlich vorhandenen 12bit-Werte gespeichert. Jeweils zwei 12bittige Sensorwerte werden in 3 Bytes gespeichert. Das zweite Byte enthält dabei 4bit aus dem ersten und 4bit aus dem zweiten Sensorwert. Die anderen zwei Bytes enthalten die restlichen 8bits der Sensorwerte. Das vergrö¶ßert zwar den Aufwand beim Scheiben bzw. Lesen, spart aber ganz offensichtlich jede Menge Platz und verkürzt die notwendige Zeit für das Speichern der Bilder auf die Speicherkarte. Zur Kontrolle noch die Rechnung für die C-8080: 3280 * 2453 * 1.5 + 16672 = 12085432 Bytes Die fehlenden 6348 Bytes drücken wir einfach mal in den Skat, das passt schon 😉 Als nächstes wäre dann wohl die E-1 an der Reihe. Fixe Dateigrö¶ße: 10661632 Bytes. Latentes Bild: 2624*1966 mit 12bit Auflö¶sung. Gespeichert werden wiederum jeweils 16bit pro Sensorwert. Erste Adresse der Sensordaten ist 344064 (Metadaten + Vorschaubild). Nur zur Kontrolle: 2624 * 1966 * 2 + 344064 = 10661632 Bytes 😉 Dann bliebe noch die E-300. Meine Erkenntnisse beziehen sich dabei auf ein einziges Rawbild (FW: 1.011). Irgendwie scheint es da auch grö¶ßere, offenbar wieder redundant gespeicherte Dateien zu geben… Fixe Dateigrö¶ße: 14127616 Bytes. Latentes Bild: 3360*2504 mit 12bit Auflö¶sung. Erste Adresse der Sensordaten ist 666112 (Metadaten + Vorschaubild). Die Kontrollrechnung liefert das von der C-Serie bekannte Ergebnis: 3360 * 2504 * 2 + 666112 = 17492992 Bytes Ok, entfernen wir also wieder die Redundanz analog zur C-Serie: 3360 * 2504 * 1.5 + 666112 = 13286272 Bytes örks. Versuchen wir mal, das Pferd von hinten aufzuzäumen. StripOffsets + StripByteCount sollte gleich der Dateigrö¶ße sein: 666112 + 13461504 = 14127616 Bytes Ok, wenigstens das scheint zu stimmen 😉 Teilen wir also einfach mal die gesamte Datenmenge (StripByteCount) auf die Zeilen auf: 13461504 / 2504 = 5376 Bytes pro Zeile Aus diesen 5376 Bytes müssen sich also irgendwie die 3360 Spaltenwerte berechnen lassen. Bei eingehender Betrachtung der Rawdaten fällt auf, daß jedes 16. Byte Null ist. Ignorieren wir also einfach 1/16 der Rawdaten und widmen uns den verbleibenden 5040 Bytes pro Zeile. Aus 3 Bytes ergeben sich jeweils zwei 12bittige Sensorwerte (s. C-Serie): 5040 / 1.5 = 3360 Die neue, auch die Füllbytes berücksichtigende Rechnung sieht dann so aus: 3360 * 2504 * 1.6 + 666112 = 14127616 Bytes Bingo. Die Rawdaten der E-300 enthalten also im Gegensatz zur C-Serie 1/16 Redundanz (Füllbytes). Im Gegensatz zu den 4/16 Redundanz in den ORF-Dateien der E-1 eine gewaltige Platzersparnis, ohne dabei auf den Vorteil der gelegentlichen Datenausrichtung (führt u.a. zu einem schnelleren Prozessorzugriff) zu verzichten. Die Olympus-Entwickler sind eben immer für eine Überraschung gut 😉 Abschließend kommen wir nochmal auf die Frage Sind ORF-Dateien —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 9:59:59 Alexander Krause Alta, Ey… Eischhö¶rnschin sin´ einfach krass, wa! Alex — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 10:38:05 Heinz Winter Hallo Frank,alle Achtung Du hast Dir ja ganz schö¶n Mühe gemacht uns Unwissendes Volk aufzuklären,ganz ehrlich am Anfang verstand ich mehr oder weniger nur ‚Bahnhof‘ aber nach mehrmaligem durchlesen hab ich doch so einiges kapiert,solltest Mathematiker werden Junge(oder bist Du’s vielleicht sogar?),aber wie auch immer selbst in meinem Alter lernt man immer noch dazu. Ein Dankeschö¶n aus Nürnberg,Heinz. — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 12:07:08 Hannes Heinz Winter schrieb: > Hallo Frank,alle Achtung Du hast Dir ja ganz schö¶n Mühe gemacht > uns Unwissendes Volk aufzuklären,ganz ehrlich am Anfang verstand > ich mehr oder weniger nur ‚Bahnhof‘ aber nach mehrmaligem > durchlesen hab ich doch so einiges kapiert,solltest Mathematiker > werden Junge(oder bist Du’s vielleicht sogar?),aber wie auch > immer selbst in meinem Alter lernt man immer noch dazu. > Ein Dankeschö¶n aus Nürnberg,Heinz. Ich würde mal eher auf Informatiker tippen… Sag mal Frank du scheinst dich ja ein wenig mit den Dateien auszukennen… weißt du zufällig wie man genauer die einzellnen Sensordaten interpretieren muss (abwechselnd RGB???) … habe mir eine E-1 bestellt (war schon kurz bei mir nur leider defekt… nun muss ich wieder warten…) aber vielleicht ist mir ja mal langweilig und ich komme aud die Idee mir einen einfachen RAW-Konverter selber zu programmieren… man weiß ja nie 😉 Gruß Hannes — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 14:17:55 Heiko Kanzler Hannes wrote: > ja mal langweilig und ich komme aud die Idee mir einen einfachen > RAW-Konverter selber zu programmieren… man weiß ja nie 😉 Soviel Zeit mö¶chte ich mal haben *gggg* Problematisch dürfte wohl die Interpolation der Werte werden… Das ist ja schliesslich das Geheimniss eines guten RAW-Konverter. — Liebe Grüße aus Berlin, Heiko Kanzler http://www.heikokanzler.de Ich produziere mit viel zu hohem finanziellen Aufwand miserable —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 16:17:58 Hannes >> ja mal langweilig und ich komme aud die Idee mir einen einfachen >> RAW-Konverter selber zu programmieren… man weiß ja nie 😉 > > Soviel Zeit mö¶chte ich mal haben *gggg* > Problematisch dürfte wohl die Interpolation der Werte werden… Das > ist ja schliesslich das Geheimniss eines guten RAW-Konverter. > Neee, will ja keinen GUTEN RAW-Konverter programmieren (so viel Zeit habe ich auch nicht…) evtl. kö¶nnte ich mir halt nur vorstellen, dass ich eines Nachmittags mal Lust habe mir die Original Sensordaten anzugucken (das sind nur ein paar Zeilen Code… wenn man weiß wie die Daten zu interpretieren sind… und wäre meiner Ansicht nach schon mal sehr interessant). Und wenn ich dann noch Lust habe würde ich das Ganze vielleicht um einen trivialen Bildverarbeitungs-Algortihmus (vergleichbar einer bilinearen Interpolation jedes einzellnen Farbkanals auf die volle Auflö¶sung) erweitern und fertig wäre ein kleiner RAW-Konverter den man mal eben an einem Nachmittag programmiert hat… Gruß Hannes — posted via https://oly-e.de —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 16:19:10 Frank Ledwon Heiko Kanzler wrote: > Problematisch dürfte wohl die Interpolation der Werte werden… Das > ist ja schliesslich das Geheimniss eines guten RAW-Konverter. Nicht wirklich 😉 Das inzwischen von so ziemlich jeder Software eingesetzte Verfahren Interpolation using a Threshold-based variable number of —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 16:19:40 Frank Ledwon Alexander Krause wrote: > Alta, Ey… > > Eischhö¶rnschin sin´ einfach krass, wa! Je härter die Nußschale, umso leckerer ist der Inhalt 😉 Wenn jetzt noch irgendein Nagetierliebhaber die große“ E-300-Nuß —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 16:19:44 Frank Ledwon Hannes wrote: >> [..] solltest Mathematiker werden [..] > > Ich würde mal eher auf Informatiker tippen… Heiß 😉 Außerdem diensthabendes Eichhö¶rnchen, Hüter des heiligen Grals der EXIF-Daten und offizieller Beauftragter für statistische Angelegenheiten von oly-e.de 😉 > Sag mal Frank du scheinst dich ja ein wenig mit den Dateien > auszukennen… Anzunehmen 😉 > weißt du zufällig wie man genauer die einzellnen > Sensordaten interpretieren muss (abwechselnd RGB???) … Da gibt es auch bei den von Olympus eingesetzten CCDs verschiedene Anordnungen. Das genaue Bayer-Muster steht aber glücklicherweise bei allen ORF-Dateien in den Metadaten. Für die E-1 sieht das Tag so aus: CFAPattern = 2×2=GRBG Daraus ergibt sich dann folgendes Muster: GRGRGRGR BGBGBGBG GRGRGRGR BGBGBGBG > aber vielleicht ist mir ja mal langweilig und ich komme aud die Idee > mir einen einfachen RAW-Konverter selber zu programmieren… man > weiß ja nie 😉 Alles weitere ist dann zu komplex, um es mit wenigen Worten umfassend beschreiben zu kö¶nnen. Deshalb nur ein Schnelldurchlauf: Die Sensordaten werden aus der Datei eingelesen und in eine RGB-Struktur entsprechend der Anordnung (CFAPattern) geschrieben. Danach folgt die Interpolation der fehlenden Farbwerte aus den tatsächlich vorhandenen Sensorwerten. Für den Anfang reicht dabei eine bilineare Interpolation (der fehlende Farbwert ergibt sich einfach aus dem Mittelwert der vorhandenen Farbwerte aus den Nachbarpixeln) vö¶llig aus. Nach der Interpolation folgt dann noch die eigentliche Magie, nämlich die Transformation in den normalen RGB-Farbraum einschließlich notwendiger Gamma- und WB-Korrekturen. Dafür muß man aber dann schon mehr als nur Langeweile haben 😉 Squirrel —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 17:05:54 Hannes Vielen Dank für die ausführliche Antwort Kollege“ (schreibe —————————————————————————————————————————————— Datum: 01.06.2005 Uhrzeit: 17:40:52 Heiko Kanzler Frank Ledwon wrote: > Wofür aber steht das ‚SR‘ der C-Serie? Doch nicht etwa für > SchonRaum?! *muaahaaaa* 😉 — Liebe Grüße aus Berlin, Heiko Kanzler http://www.heikokanzler.de Ich produziere mit viel zu hohem finanziellen Aufwand miserable —————————————————————————————————————————————— Datum: 04.06.2005 Uhrzeit: 23:35:58 Frank Ledwon Hannes wrote: > Vielen Dank für die ausführliche Antwort Kollege“ (schreibe —————————————————————————————————————————————— Datum: 04.06.2005 Uhrzeit: 23:36:00 Frank Ledwon Frank Ledwon wrote: > Abschließend kommen wir nochmal auf die Frage Sind ORF-Dateien —————————————————————————————————————————————— Datum: 06.06.2005 Uhrzeit: 9:19:29 Heiko Kanzler Frank Ledwon wrote: > Ich hatte ja eigentlich mit etwas mehr Protest gerechnet, aber > offenbar war die Argumentationskette viel zu schlüssig 😉 Na ja, DU hast reingeschaut. ICH gehe im Stillen immer noch davon aus das die Sensor-Daten verlustfrei (RLE?) komprimiert sind 😉 — Liebe Grüße aus Berlin, Heiko Kanzler http://www.heikokanzler.de Ich produziere mit viel zu hohem finanziellen Aufwand miserable —————————————————————————————————————————————— Datum: 06.06.2005 Uhrzeit: 22:05:39 Frank Ledwon Heiko Kanzler wrote: > Frank Ledwon wrote: > >> Ich hatte ja eigentlich mit etwas mehr Protest gerechnet, aber >> offenbar war die Argumentationskette viel zu schlüssig 😉 > > Na ja, DU hast reingeschaut. ICH gehe im Stillen immer noch davon > aus das die Sensor-Daten verlustfrei (RLE?) komprimiert sind 😉 E-10 und E-20 liefern jeweils 10bit, die E-1 liefert bereits 12bit Daten pro Sensor. Bei allen drei Kameras wird dieser Wert mit Nullbits aufgefüllt und als 16bit-Wort in die ORF-Datei geschrieben: E-x0:  [xxxx xxxx][xx– —-] E-1:   [xxxx xxxx][xxxx —-] Ein Sensorwert belegt also immer 2 Byte (=16bit) Speicher. Bei der E-1 sind davon /nur/ 25% und bei der E-x0 sage und schreibe 37.5% Redundanz in Form von Nullbits. Bei der E-300 werden jeweils zweimal 12bit als drei 8bit-Bytes in die ORF-Datei geschrieben (Die tatsächliche Anordnung der Bits sieht anders aus und vielleicht ergibt das Ganze bei genauer Betrachtung unter Berücksichtigung der endian issues“ sogar einen ——————————————————————————————————————————————
