Archiv verlassen und diese Seite im Standarddesign anzeigen : 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
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
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
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
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
Ich verstehe nix. So genau muß ich es auch gar nicht wissen. Trotzdem Danke.
Andys
AndreasP
23.10.2003, 10:35
xxx
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
Hallo,
Das wird langsam ärgerlich mit der betreffenden Firma ! :)
Die Frage wurde schon mal an anderer Stelle beantwortet:
http://www.network54.com/Forum/message?forumid=151930&messageid=1064991466
Dies war die Antwort von jemandem der eine RAW Konverter für die A1 geschrieben hat.
(Anmerkung ein Nibble sind 4 bit)
16bit -4bit = 12bit
Q.e.d
MfG
Andreas
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
ISO-Star
23.10.2003, 11:45
@ 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!
AndreasP
23.10.2003, 12:44
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
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
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
ISO-Star
23.10.2003, 15:20
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
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
ISO-Star
23.10.2003, 21:24
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
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
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.
"Wir korrigieren die Enden in der Tonwertkorrektur, die Kamera macht es zwischen den Tonwerten. "
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
OK, einer kommt noch ...
"Wir korrigieren die Enden in der Tonwertkorrektur, die Kamera macht es zwischen den Tonwerten. "
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
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
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 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
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 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
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 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
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.
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.
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
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.
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 ...
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
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.
Gruss,
Rob
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
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
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
Hier Dalibors Antwort:
Hello Tom,
the answer is easy. The RAW file stores just 12 bits of data (same as for the older cameras).
According to Mark's proofs there are definitelly more data than 12 bits at the input side but I cannot tell how much precisely.
But 14 bits sounds reasonable. (There was more then 12 bits in older cameras too).
The compression is very simple as you have described.
They just pack 12 bits values together. So two pixels are 3 bytes instead of four previously used.
I'll update my description when my time schedule will allow it.
At this moment it is more important to update MRWFormat for A1 and find the meaning of new values in EXIF MakerNote.
Regards,
Dalibor
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
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.
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
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.
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
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...
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.
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
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...
ich verstehe die fortsetzung der Diskussion nicht. Minolta sagt doch klar, ich arbeite mit 14 bit.
Andys
ich verstehe die fortsetzung der Diskussion nicht. Minolta sagt doch klar, ich arbeite mit 14 bit.
Andys
Programmcode luegt nicht:
if (!strcmp(model,"DiMAGE A1"))
load_raw = packed_12_load_raw;
... und da steht 12. Details unter http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
ich verstehe die fortsetzung der Diskussion nicht. Minolta sagt doch klar, ich arbeite mit 14 bit.
Andys
Programmcode luegt nicht:
if (!strcmp(model,"DiMAGE A1"))
load_raw = packed_12_load_raw;
... und da steht 12. Details unter http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
Muss man das verstehen??
Andys
Muss man das verstehen??
Andys
Ja, wenn man diesen Thread gelesen hat, speziell mein vorhergehendes Posting.
Muss man das verstehen??
Andys
Ja, wenn man diesen Thread gelesen hat, speziell mein vorhergehendes Posting.
Ich meine das http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
Andys
Ich meine das http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
Andys
Nein, das muss man nicht verstehen ;)
Aber wer's versteht wird von dem Glauben abfallen das A1 RAW-Format speichere mit 14Bit ab.
Unter Datenkompression verstehe ich etwas anderes, z.B. verlustfreie Algorithmen nach Huffman (LZW etc.).
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
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.
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
Du kannst Dich aber retten indem Du argumentierst alle 12Bit-Worte seine gleich wahrscheinlich (und statistisch unabhaengig).
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
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. ....
ich verstehe die fortsetzung der Diskussion nicht. Minolta sagt doch klar, ich arbeite mit 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
Du kannst Dich aber retten indem Du argumentierst alle 12Bit-Worte seine gleich wahrscheinlich (und statistisch unabhaengig).
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
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
Hey Tom,
selbst mit WinZip ist bei höchster Kompressionsstufe nicht mehr viel holen.
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...
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
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
Und wo nicht alle möglichen Werte belegt werden, läßt sich auf jeden Fall etwas komprimieren, oder nicht? (s.o.)
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
Hallo Ihr zwei Komprimierer,
ich habe mir die Laubdatei mal angeguckt und *ausgerechnet* welche Information pro Pixel noetig ist wenn man die Differenzen der RAW-Werte codiert (Technisch ist das eine einfache DPCM mit Entropiecodierung). Dabei habe ich natuerlich die Farbanteile getrennt betrachtet.
Fuer Gruen benoetigt man bei diesem Bild mindestens 5,21 Bit/Pixel, fuer Rot und Blau sind es 5,33 Bit/Pixel. Die Kompression nach dieser Methode kommt also auf ca. 43% der Originalgroesse. Originalgroesse bezieht sich auf das schon "gepackte" 12Bit Format. Overhead ist nicht eingerechnet.
Allround-Komprimierer wie ZIP schaffen diese Rate nicht, da sie die Abhaengigkeiten nicht so gut ausnutzen.
Wer eine exakte Erklaerung haben moechte, den muss ich aber auf mindestens das Wochenende vertroesten ;)
Gruss,
Rob
Hallo Ihr zwei Komprimierer,
ich habe mir die Laubdatei mal angeguckt und *ausgerechnet* welche Information pro Pixel noetig ist wenn man die Differenzen der RAW-Werte codiert (Technisch ist das eine einfache DPCM mit Entropiecodierung). Dabei habe ich natuerlich die Farbanteile getrennt betrachtet.
Fuer Gruen benoetigt man bei diesem Bild mindestens 5,21 Bit/Pixel, fuer Rot und Blau sind es 5,33 Bit/Pixel. Die Kompression nach dieser Methode kommt also auf ca. 43% der Originalgroesse. Originalgroesse bezieht sich auf das schon "gepackte" 12Bit Format. Overhead ist nicht eingerechnet.
Allround-Komprimierer wie ZIP schaffen diese Rate nicht, da sie die Abhaengigkeiten nicht so gut ausnutzen.
Wer eine exakte Erklaerung haben moechte, den muss ich aber auf mindestens das Wochenende vertroesten ;)
Gruss,
Rob
Hey Rob,
Du scheinst ja wirklich Ahnung von den Thema zu haben.
Das mit den nicht mal 6 bit pro Pixel schockiert mich schon etwas (und da streiten wir uns, ob mit 12 oder 14 Bit abgespeichert wird... :shock: )
Ich vermute aber mal, daß es auch mit dem Motiv zu tun hat.
Ich wäre sehr an einer weiteren Erläuterung interessiert, aber laß Dir ruhig Zeit damit. da ich momentan auch nur sehr unregelmäßig ins Forum schauen kann...
Tom
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).
Tom
Das ist so nicht ganz richtig. Ich fotografiere fast nur im RAW, und bin immer wieder überrascht, dass die Werte fast immer genutzt werden.. Selbt bei Aufnahme bei hellem Licht ohne Sonnenschein werden die Grenzen erreicht. Und bei leichtem Sonnenschein wird der Bereich überschritten. Das Histogramm in der Kamera zeigt das ganze falsch an, vor allem das Livehistogramm. Deswegen hätte es für mich persönlich nur einen echten Grund des Umstiegs von Hi auf A1, die 14 Bit, wenn sie vorhanden gewesen wären. Alles andere wären nur freundliche Beigaben.
Andys
bleibert
03.11.2003, 22:06
Das Histogramm in der Kamera zeigt das ganze falsch an, vor allem das Livehistogramm.
Ja, damit bin ich auch schon schwer eingefahren. Vor allem bei Kompaktkameras scheint es beliebt zu sein, den G-Kanal als Histogramm herzunehmen (da 50% aller Pixel grün sind, liefert der Kanal eine gute Flächendeckung und ist ohne Interpolation schnell verfügbar). Wenn man dann zB Hauttöne fotografiert kann man bei schön ausgebrannten Lichtern enden, obwohl das kamerainterne Histogramm kein clipping anzeigte. Auch bei den DSLR's herrscht hier Notstand, außer der Fuji S2 und der Sigma SD10 haben alle nur Luminanz-Histogramme.
Gruß
Dennis.
Und daß in so gut wie keinem Bild ALLE möglichen Werte vorhanden sind...
Tom
Das ist so nicht ganz richtig. Ich fotografiere fast nur im RAW, und bin immer wieder überrascht, dass die Werte fast immer genutzt werden.. Selbt bei Aufnahme bei hellem Licht ohne Sonnenschein werden die Grenzen erreicht. Und bei leichtem Sonnenschein wird der Bereich überschritten. Das Histogramm in der Kamera zeigt das ganze falsch an, vor allem das Livehistogramm. Deswegen hätte es für mich persönlich nur einen echten Grund des Umstiegs von Hi auf A1, die 14 Bit, wenn sie vorhanden gewesen wären. Alles andere wären nur freundliche Beigaben.
Andys
Das relativiert die Sache natürlich.
Ich weiß auch nicht, ob das Live-Histogramm bei RAW oder JPG anders anzeigt...
Tom
U.Schaffmeister
06.11.2003, 01:18
Ich glaube das einige in diesem Thread ein paar Dinge miteinander vermischen, die man so nicht vermischen sollte:
Der Kontrastumfang wird durch den hellsten und dunkelsten Pixel markiert, den die Kamera zu liefern im Stande ist. Dieses sind erst einmal analoge Werte, die Digitalisiert werden müssen. Die Genauigkeit der Digitalisierung wird durch die Bit-Auflösung bestimmt. Jede Erhöhung der Auflösung bringt somit nur feinere Differenzierungen, aber auf keinen Fall einen höheren Kontrastumfang.
Geht man nun davon aus das sich die Helligkeitswerte logarithmisch zunehmen müssen, um gleichbleibende Helligkeitssprünge zu erzielen, dann ist es durchaus denkbar aus gespeicherten 12 bit eine 14 bit Auflösung zu generieren. Dies läßt sich zum Beispiel über eine anschließende Konvertierung in eine größere Auflösung erreichen. Das Histogramm sollte dann durchaus Lücken aufweisen, wobei in den hellen Bereichen mehr Lücken sein dürfen als in den dunklen.
Werden 14 bit Farbwerte nun zur Bearbeitung in 16 bit umgerechnet, dann gibt es auf jeden Fall Lücken innerhalb des Histogramms, die sich wieder minimieren wenn das ganze auf 8 Bit zurückkonvertiert wird.
bleibert
06.11.2003, 15:49
Jede Erhöhung der Auflösung bringt somit nur feinere Differenzierungen, aber auf keinen Fall einen höheren Kontrastumfang.
Soweit, so gut. Aber ein Chip mit einem größeren Dynamikbereich benötigt auch eine höhere bit-Zahl bei der Quantisierung, wenn die Abstufungen hinreichend klein bleiben sollen. Insofern hört sich ein Chip, der mit 14bit aufzeichnet verdächtig nach größerer Dynamik an.
Gruß
Dennis.
So, am WE hab ich mal zusammengeschrieben wie weit sich Toms Laub-Bild komprimieren laesst mit ordentlicher Kompression. Leider ist mir dabei aufgefallen, dass mich mein Rawkonverter veraeppelt hat und nicht 5 Bit/Pixel sondern ca. 8 Bit/Pixel noetig sind. Sorry, Fehler meinerseits. Aber immerhin bin ich noch wesentlich besser als ZIP und RAR ;)
Hier der Link: Kompression von RAW-Dateien (http://www.lnt.de/~baeuml/privat/rawcomp.pdf)
Feedback, wie immer, erwuenscht.
Gruss,
Rob
Hey Rob,
da hat sich aber jemand Arbeit gemacht - alle Achtung! :shock:
Wer ich mir nachher mal in Ruhe durchlesen... Schon mal besten Dank!!! Das kannst ja mal nach Osaka schicken - vielleicht interessiert die das...
Dat Ei
Hey Rob,
da hat sich aber jemand Arbeit gemacht - alle Achtung! :shock:
Wer ich mir nachher mal in Ruhe durchlesen... Schon mal besten Dank!!! Das kannst ja mal nach Osaka schicken - vielleicht interessiert die das...
Dat Ei
Na, ich denke mal die Ingenieure in Osaka wissen das alles schon, obwohl - wenn ich mir angucke dass sie bei meiner 7i 12 Bit in 2 Byte abspeichern kommen mir so leise Zweifel ... :roll:
/Rob
@r0b
ist das nicht logisch 12 Bit in 2 Byte.
Ich dachte immer 8 Bit = 1 Byte und um keine 1,5 Byte zu speichern speichern sie 2 Byte?
Viele Grüße
Matze
Hey Matze,
so ist es in der ganzen D7x-Serie gemacht worden Dadurch wurde pro Pixel ein halbes Byte verschenkt. Da ist das Format der A1 doch etwas effizienter, wenn auch unter Gesichtspunkten der reinen Dateigröße noch nicht optimal.
Dat Ei
Aha,
wenn also eh 2 Byte gespeichert werden, könnten sie aber auch gleich volle 16 Bit = 2,0 Byte verwenden. Oder macht das keinen Sinn?
Viele Grüße
Hey Matze,
das Problem ist der A/D-Wandler samt des nachgelagerten internen Prozesses. Der A/D-Wandler der D7x wandelt nur mit 12bit Auflösung. Ihn auf 16bit aufzubohren, würde wahrscheinlich angesichts des CCSs nur die Scheingenauigkeit erhöhen.
Dat Ei
U.Schaffmeister
11.11.2003, 23:56
Jede Erhöhung der Auflösung bringt somit nur feinere Differenzierungen, aber auf keinen Fall einen höheren Kontrastumfang.
Soweit, so gut. Aber ein Chip mit einem größeren Dynamikbereich benötigt auch eine höhere bit-Zahl bei der Quantisierung, wenn die Abstufungen hinreichend klein bleiben sollen. Insofern hört sich ein Chip, der mit 14bit aufzeichnet verdächtig nach größerer Dynamik an.
Gruß
Dennis.
Nach dieser Logik wäre ein Kuchen der durch 14 Personen geteilt wird immer größer als ein Kuchen der durch 12 Personen geteilt wird...
Also immer erst mal feststellen wie groß der Kuchen ist, und dann entscheidet sich automatisch wie klein die Stücke für den einzelnen sind.
Die zweite Frage, die dann noch zu klären ist, lautet wie folgt: Sollen alle Personen qualitativ gleichwertige Stücke bekommen, oder reicht eine mengenmäßig gleiche Verteilung?
Und was lernen wir daraus? Die Angabe einer Bit-Auflösung ist nur in Zusammenhang mit dem Dynamikumfang und der verwendeten Digitalisierungsmethode interessant.
U.Schaffmeister
12.11.2003, 00:01
Aha,
wenn also eh 2 Byte gespeichert werden, könnten sie aber auch gleich volle 16 Bit = 2,0 Byte verwenden. Oder macht das keinen Sinn?
Viele Grüße
Könnten sie, allerdings würde dadurch die Dateigröße anwachsen, da in 4 Byte Bilddaten 1 Byte Nutzlosdaten enthalten sind. Da größere Dateien wiederum längere Lade- und Speicherzeiten beanspruchen wäre das ganze kontraproduktiv.