A1 - 14 Bit
 

Die klare Antwort von Minolta zu meiner Frage, wegen der 14 Bit.

"> Wenn Sie die Bildqualität auf RAW stellen, werden die 14 Bit der DiMAGE
> A1 mitgespeichert."

Andys

Re: A1 - 14 Bit
 

Die Frage sollte man mal Dalibor Jelinek stellen.
Der weiß wahrscheinlich mehr über die RAW-Formate der D7-Reihe und A1 als der Minolta-Support, da er RAW-Plugins für Photoshop programmiert (auch für die A1)...
http://www.dalibor.cz/minolta/plugin.htm

RAW-Format-Beschreibung D5/7_:
http://www.dalibor.cz/minolta/raw_file_format.htm

Tom

Re: A1 - 14 Bit
 

Ich verstehe nix. So genau muß ich es auch gar nicht wissen. Trotzdem Danke.
Andys

Re: A1 - 14 Bit
 

xxx

Re: A1 - 14 Bit
 

Ich habe ja auch schon nachgehakt. Denn für mich ist die Antwort nicht so eindeutig, dass ich 14 Bit zum Arbeiten habe. das ist entscheidend.

Andys

@ all:

':cry:'Auch auf die Gefahr hin, als Unbedarfter entlarvt zu werden: Worüber sprecht Ihr hier eigentlich?

Gut, die A1 hat einen 14 bit-Wandler. was auch immer das heißen mag. Woanders sind es dann nur noch 12. Also 2 bit verschwunden.

Wäre jemand so hilfsbereit, mir in verständlichem, allgemeinem Deutsch den Sachverhalt zu erklären. Danke!

xxxx

Das einzige was ich mir vorstellen kann ist, dass die 14 Bit zur Vorverzerrung mit einer Kontrast-Korrekturkurve herangezogen werden, so dass kein schwach besetztes Histogramm in 12 Bit vorliegt. Die icc-Profile der D7 Serie hatten naemlich ein iTRC-Tag, das nicht standardisiert ist und nur von entsprechenden Programmen (DIVU etc.) ausgewertet werden konnte. Wird diese Korrektur nun in der Kamera vorgenommen, kann ein Standard-konformes icc-Profil verwendet werden.

Kann sich mal jemand das A1-Profil vornehmen und nachgucken?

Gruss,
Rob

Rob, bitte erklären. Das verstehe ich nicht.
Andys

Gerne ;)

Mit 12 Bit kann ich 2^12=4096 Werte darstellen. Damit kann jede Farbe, die ich vom CCD auslese, (theoretisch) 4096 verschiedene Werte annehmen. Wenn ich eine Kontrastkorrektur vornehme, wird jedem Farbwert ein neuer Wert zugewiesen. Bsp:
0 -> 0
1 -> 1
2 -> 3
3 -> 4
4 ->6
5 -> 7
6 -> 9
7 -> 10
8 -> 12
...
4093 -> 4094
4094 -> 4095
4095 -> 4095

Dabei entstehen Luecken, hier gibt es bsp. keine 2,5,8,11 mehr. Das Histogramm sieht also teilweise wie ein Kamm aus, da bestimmte Werte nicht mehr vorkommen koennen. Das meinte ich mit schwach besetzt.
Wenn ich das ganze aber in 14 Bit vornehme habe ich dieses schwach besetzte Histogramm auch, aber nach einer Wandlung 14->12 Bit eben nicht mehr, da je 4 Werte zu einem zusammengefasst werden, was das Histogramm "glaettet".

Ich hoffe das war verstaendlich?

Gruss,
Rob

Hallo Rob,

schon mein Professor hat jedesmal das Gesicht verzogen, wenn er und etwas erklären sollte, was für ihn doch so einfach und selbstverständlich war.

Von wegen. Versuch doch mal, Dich in die gehirngänge normal denkender und nur mittelmäßig intelligenter menschen hinein zu versetzen. AAAh! geht doch!

Also, lieber Rob, bitte noch mal zum Mitschreiben: Von was redest Du hier (bei allem Respekt Dir gegenüber!). Ein Tipp: Tu einfach so, als sei ich jemand von der Straße, der nur begeistert so 'ne Digi in der hand hält und die Welt verstehen möchte.

Bluesky

Lieber Bluesky,

vielen Dank für den Hinweis. Ich gelobe Besserung und werde mich in Zukunft etwas zügeln :roll:

Gruß,
Rob

Hey rOb,

... öhmm...also...wärst Du denn so nett und startest noch mal 'nen Anlauf? Ich denke, Du bist ziemlich fit auf dem Gebiet hier und würde mich über eine normalo-deutsche Antwort echt freuen! ':D' Versuche auch, Dir zu folgen...

Grüße

Bluesky

Man wir haben ja lauter Wissenschaftler in unseren Reihen.

Wenn ich Dich richtig verstehe, dann hängt die Güte der 12 bit von der Güte der Autokorrektur ab, wie ich das irgenwo mal angedeutet habe. Wir korrigieren die Enden in der Tonwertkorrektur, die Kamera macht es zwischen den Tonwerten.
Andreas

OK, einer kommt noch ...

Wie gesagt, das ist alles Spekulation, aber einen anderen Grund kann ich mir nicht vorstellen daß einfach nur 12 von den 14 Bit abgespeichert werden:

Die alten 7, 7i und 7hi haben bei der Aufnahme jeden Pixel mit 12 Bit dargestellt. Die A1 verwendet nun angeblich 14 Bit pro Pixel bei der Aufnahme. Das heißt, die A1 kann (theoretisch) die Farbwerte etwas genauer (Kontrastumfang, Farbnuancen, ...) darstellen. Diese größere Genauigkeit büßen die Bilder aber ein, da die A1 von den 14 Bit nur 12 abspeichert im RAW-Format. 2 bit Genauigkeit gehen dabei verloren. Was soll das ganze also? Reiner Marketinggag?

Ich vermute eben, daß die A1 noch eine kleine Vorverarbeitung der Bilddaten vornimmt - könnte diese Kontrastkorrektur sein - und erst dann abspeichert. Die Vorverarbeitung wird eben mit dieser größeren Genauigkeit noch vorgenommen, was in manchen Fällen Vorteile bringt, wie ich an obigem Beispiel versucht habe zu erklären.

Damit will ich aber keinesfalls die Marketingblenderei um die 14 Bit gutheißen. Ich möchte nur eine Plausibiltätserklärung liefern, wozu man die etwas höhere Auflösung (in Bit pro Pixel, nicht Bildgröße) verwenden kann. Ob Minolta das tatsächlich tut und ob es einen sichtbaren Effekt hat bleibt dahingestellt.

Ich bin mir nicht sicher ob ich das verstanden habe, aber ich glaube nicht daß es das ist was du meinst. Die Kamera macht (wenn das stimmt was ich mir denke) schon so etwas ähnliches wie Du auch wenn Du an den Tonwerten drehst.

Jetzt hab ich mich aber wirklich bemüht, ich hoffe es hat etwas gebracht ...

Gute Nacht,
Rob

Wenn ich mit 12bit digitalisiere und auch 12bit ausweise, habe ich zwangsweise auch das Rauschen im Ergebnis. Messe ich mit 14bit und lasse die untersten beiden Bits die der Ergebnisdarstellung weg, kappe ich auch das Rauschen, weil ich die/mehr unsicheren Bits ignoriere.

Dat Ei

Die Grundüberlegung deckt sich mit meiner Vermutung. Wenn ich fotogafiere, erzeuge ich eine durchgehende Scala an Tonwerten. Das einzige was passieren kann, ist, dass Anfang und Ende (Lichter und Schatten) fehlen. In der Tonwertkorrektur schiebe ich die Regler an beide Enden. Damit habe ich eine Korrektur vorgenommen.
Eine Zweite Möglichkeit ist, dass man die Tonwerte nimmt wie sie sind, und sie auf eine geringere Tiefe setzt, ohne sie zu korrigieren. einfach nur eine Spiegelung.
So wie ich es bisher bei der Dimage verstanden habe, entstehen in den Tonwerten lücken. ein paar Tonwerte, ein paar nichts, ein paar Tonwerte, ein paar nichts. Das zu korrigieren wird schwieriger, da ich da nicht eingreifen kann. Ich kann die Lücken nicht wegradieren.
Wenn früher durch Fehler in der Bildbearbeitung solche Lücken entstanden sind, hat man sich selbst getäuscht. Man hat das Bild um 1 Pixel vergrößert oder verkleinert. Durch die Neuberechnung sah das Histogramm schön aus, ohne lücken. In diesem Fall sind nur die Pixel wiederholt worden. Das Programm konnte keine neuen Tonwerte hinzurechnen.
Ich könnte mir denken, dass man bei der Dimage die Lücken kennt, sie Software mässig erkennt und einfach die Tonwerte zusammen rücken lässt. So erhält man sich die Enden, die entscheidend werden. Auf die kommt es an. Sie bringen die bessere zeichnung in Lichter und Schatten.
Andys

Ich lass mich gerne belehren aber ich habe das Gefühl das Du hier zwei Sachen durcheinander wirfst. Einmal die Vergößerung bei der fehlende Pixel interpoliert werden müssen, und ein anderes Mal Löcher im Histogramm die durch zu große Spreizung kommen.

Basti

Erkläre bitte estwa genauer was Du meinst. Ich ahne was Du meinst:
Andys

Der Trick mit der geringfuegigen Vergroesserung funktioniert wahrscheinlich schon, da alle Pixel neu berechnet werden durch Interpolation (schon wieder so ein Unwort :roll:). Nach der Neuberechnung kommen mit grosser Wahrscheinlichkeit auch die Farben wieder vor, die vorher wegen der Tonwertspreizung nicht mehr exisitiert haben.

Ich glaube eher dass das Rauschen im Analogsignal vor der Digitalisierung auch schon vorhanden ist. Aber mit 14 Bit kann man das Rauschen dann natuerlich noch genauer darstellen, i.e. ich habe noch mehr unsichere Bits die ich dann wieder verwerfen kann ...

Gruss,
Rob

Keine Frage Rob, da sind wir uns absolut einig. Verwerfe ich aber die beiden untersten Bits (LSB), glätte ich damit das Ergebnis.

Dat Ei

Den ersten Punkt kann jeder ausprobieren. Du hast den 2 Punkt missverstanden. Es kommen keine neue Farben vor. Wie aus jeder Interpolation werden aus umliegenden Pixeln die fehlenden Farben errechnet. Daher sage ich, dass das unsinnig ist. Das macht sicher heute niemand mehr. Man belügt sich selber, weil das Histogramm schön aussieht, aber dem Bild hat es nichts gebracht.
Andys

Re: A1 - 14 Bit
 

Hier Dalibors Antwort:

Also sind tatsächlich nur 12 Bits in der RAW-Datei abgelegt, und nicht 14, wie Minolta geschrieben hat. :?

Und die neue Datenkompression ist eigentlich gar keine:
Es werden nur nicht mehr 4 von 16 bits im RAW file mit informationslosen Nullen aufgefüllt.
Statt dessen werden jetzt zwei 12bit-Datenworte auf drei Bytes im RAW file verteilt.

Tom

Photopeter hat kuerzlich einen Link auf ein Opensource Programm zum Verarbeiten von RAW Formaten gepostet: http://www.d7userforum.de/phpBB2/viewtopic.php?t=1512
Im entsprechenden Quelltext zum A1-Format werden definitiv nur 12 Bit aus der RAW-Datei gelesen, davon kann sich jeder ueberzeugen der ein wenig Ahnung von C hat.

Gruss,
Rob

Re: A1 - 14 Bit
 

Hey Tom,

wenn das keine Datenkompression ist, was dann? Es ist in meinen Augen eine einfache, verlustfreie Datenkompression. Übrigens eine Form, die in den internationalen Foren seit langem vorgeschlagen wurde.

Dat Ei

Re: A1 - 14 Bit
 

Warum sollte das eine Kompression sein?
Als Eingangsdaten werden 2x 12Bit (=24bit) auf 3x8bit (=24bit) Ausgangsdaten im RAW file verteilt.
24 bit (bzw. 3 Byte) bleiben 24 bit (bzw. 3 Byte).

Unter Datenkompression verstehe ich etwas anderes, z.B. verlustfreie Algorithmen nach Huffman (LZW etc.).

Bei den D5/7/7i/7hi-Modellen wurden für die 12bit Daten einfach 16bit im RAW file belegt (die 4 führenden bits waren immer Null).
Das war zwar eine einfache Methode, aber auch eine sehr verschwenderische bezüglich CF-Speicherplatz.

Tom

PS: Der Vorschlag die "neue" Bitverteilungs-Methode zu benutzen ist so naheliegend, daß ich es mir damals (vor ca. 2 Jahren) nicht nehmen ließ, in mehreren englischsprachigen Foren darauf hinzuweisen.
Scheinbar muß man bei Minolta öfters mal mit dem Zaunpfahl winken, bevor sich etwas tut...

Re: A1 - 14 Bit
 

ich verstehe die fortsetzung der Diskussion nicht. Minolta sagt doch klar, ich arbeite mit 14 bit.
Andys

Re: A1 - 14 Bit
 

Programmcode luegt nicht:
... und da steht 12. Details unter http://www.cybercom.net/~dcoffin/dcraw/dcraw.c

Re: A1 - 14 Bit
 

Muss man das verstehen??
Andys

Re: A1 - 14 Bit
 

Ja, wenn man diesen Thread gelesen hat, speziell mein vorhergehendes Posting.

Re: A1 - 14 Bit
 

Ich meine das http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
Andys

Re: A1 - 14 Bit
 

Nein, das muss man nicht verstehen ;)
Aber wer's versteht wird von dem Glauben abfallen das A1 RAW-Format speichere mit 14Bit ab.

Re: A1 - 14 Bit
 

Hey Tom,

ist es nicht sogar eine Form von Huffman? Wieviele Bit brauche ich zur Codierung von 2*16bit, wenn von den 16bit jeweils die oberen 4bit null sind und die restlichen 12bit Informationen enthalten können und somit nicht redundant sind.

Dat Ei

Nicht wirklich, da bei derHuffman-Codierung speziell die Auftrittswahrscheinlichkeiten der moeglichen 12Bit-Worte beruecksichtigt werden muessten (das ist gerade der Witz dabei). Du kannst Dich aber retten indem Du argumentierst alle 12Bit-Worte seine gleich wahrscheinlich (und statistisch unabhaengig). Solche Bilder moechte ich aber nicht angucken muessen :roll:

Gruss,
Rob

Hey r0b,

genau das isses. Sie codieren nicht dynamisch nach Huffman, sondern statisch apriori und halt 1:1. Huffman zielt ja in erster Linie auf die Vermeidung von Redundanzen. Hier werden nur die Redundanzen der oberen 4bit vermieden (immer null), aber nicht die, die in nicht angesprochenen Bitkombinationen eines realen Bildes liegen.

Dat Ei

Re: A1 - 14 Bit
 

Wenn ich mich nochmal auf die erwähnte Antwort von Minolta beziehen darf, dann sagt Minolta, sie SPEICHERN 14bit, was offenbar nicht stimmt.
Arbeiten kann intern der A/D-Wandler mit 14, 16, 20 bit oder wer weiß was (ich nehme mal an, hier stimmt die Angabe 14bit).

Gut, 14bit-Wandler auslesen, Bayer-Interpolation und andere Operationen mit 14/16 Bit-Genauigkeit und als letzten Schritt vor den Speichern auf 12bit umrechnen ist immer noch besser als das alles durchgängig mit nur mit 12bit (wie bei der D7_).

Tom

Hey DatEi,

ich bin kein Kompressionsexperte, aber wenn ich das richtig verstehe, was Du geschrieben hast, wo ist denn da eine Kompression oder Umcodierung, wenn Du selbst etwas von 1:1 schreibst?

M.W. funktionieren Datenkompressionsverfahren nach einer statistischen Verteilungsanalyse aller vorkommenden Datenwerte und der Zuweisung einer neuen Codierung, die dann sinnvollerweise weniger Speicherplatz in Anspruch nimmt, als die ursprünglichen Daten, da den häufiger vorkommenden Werte kürzeren Codes zugewiesen werden.
Wahrscheinlich weiß Du das ja selbst besser als ich...

Und daß in so gut wie keinem Bild ALLE möglichen Werte vorhanden sind, siehst Du, wenn Du dir mal ein Histogramm ansiehst. Meist überstreicht es nicht den ganzen Bereich von 0 bis 100% Helligkeit (besser RGB getrennt betrachten) oder je nach Tiefe der vorher gehenden Operationen können sogar zusätzliche Lücken entstehen (das Histogramm ähnelt dann eher einem Linienspektrogramm).

Wie dem auch sei, nenne es meinetwegen ruhig Kompression, was Minolta beim A1-RAW-Format anwendet, für mich ist es jedenfalls keine (richtige). ;)

Ist zwar besser, als die 25% Platzverschwendung, die D7-Benutzer bei Verwendung des RAW-Formates über sich ergehen lassen mußten, aber mit einem anständigen Datenkompressionsverfahren hätte man die Dateigröße noch erheblich mehr verringern können.
Das kann jeder selbst ausprobieren, indem er ein RAW-Bild mit Win-ZIP, WinRAR etc. komprimiert (verlustfrei).

Daß die Implementierung aufgrund fehlender Rechenleistung nicht möglich ist glaube ich weniger, denn bei der Umrechnung der Rohdaten in ein JPG-Bild steht ja auch entsprechende Rechenleistung zur Verfügung.

Aber eigentlich hieß das Thema ja "14 oder 12 bit" und nicht "Kompression ja oder nein"... :oops:

Tom

Hey Tom,

selbst mit WinZip ist bei höchster Kompressionsstufe nicht mehr viel holen. Zudem läßt das Histogramm keinen Rückschluß über die vorkommenden Datenwerte zu. RAW speichert pro Pixel, der entweder R-, G- oder B-Pixel ist, einen Wert. Das Historgamm zeigt jedoch die Verteilung der vorkommenden Grauwerte, die jedoch aus Kombination aus RGB-Werten nach der Bayer-Interpolation bestehen.

Dat Ei

Hmm, tatsächlich?
Das hatte ich anders in Erinnerung (etwa 50-60 % der ursprünglichen Größe), kann aber sein, daß ich mich täusche.
Muß ich nochmal mit einem D7-RAW-file testen, ist schon eine Weile her...

Hast Du das mit einem D7- oder A1-Raw-file ausprobiert?

Mit dem A1-Raw-file http://mitglied.lycos.de/klabz/A1_RAW/
komme ich zu folgendem Ergebnis:

unkomprimiert: 7,19 MB
ZIP: 6,81 MB (95% der ursprünglichen Größe)
RAR: 5,89 MB (82% der ursprünglichen Größe)
jeweils mit WinZIP und WinRAR-Standardeinstellung.

Hört sich nicht gerade viel an, aber je nach Bildinhalt lassen sich wahrscheinlich noch höhere Kompressionsraten erzielen (das Beispielbild ist recht detailreich, daher schlecht zu komprimieren).
Selbst mit diesen Werten (RAR) ließen sich auf einem 1GB-Microdrive 31 RAW-Bilder mehr unterbringen als original A1-RAW-Bilder.
Gegenüber dem D7-RAW-Format (9,5MB) wären es schon 66 Bilder mehr...

Um die Luminanz (Helligkeit, Grauwert) für das Histogramm zu berechnen, werden R-, G-, und B- Werte mit verschiedenen Faktoren multipliziert, um die CCD-Primärfarben-Empfindlichkeit an die Empfindlichkeitskurve (Spektralkurve) des menschlichen Auges anzugleichen. Die Folge ist, daß man nicht einfach die Histogramme R, G und B übereinanderlegen kann, sondern erst, nachdem sie horizontal "gestaucht" oder "gestreckt" worden sind (je nach dem Faktor für R, G und B).
Das führt dazu, daß eine "Lücke" in einer der Primärfarben-Histogramme bei der Überlagerung mit einem der anderen Primärfarben-Histogramme "aufgefüllt" werden kann, d.h. daß im Luminanzhistogramm diese Lücke nicht mehr zu erkennen ist.
Umgekehrt kann aber eine Lücke im Luminanzhistogramm nur dann vorkommen, wenn alle 3 (bereits gestreckten) Primärfarbenhistogramme genau an dieser Stelle auch eine Lücke aufweisen.

Das wollte ich eigentlich mit meinem Hinweis "besser RGB getrennt betrachten" sagen.

Und wo nicht alle möglichen Werte belegt werden, läßt sich auf jeden Fall etwas komprimieren, oder nicht? (s.o.)

Tom

Hey Tom,

die Frage läßt sich nicht pauschal beantworten. Jedes Umkodieren erzeugt neuen Overhead, der manchmal größer als die Ersparnis ist.

Dat Ei