ennjott Posted December 19, 2006 Share #161 Posted December 19, 2006 Advertisement (gone after registration) Da braucht man kein Professor der Informatik zu sein, um die Tragweite dieser Aussage zu erkennen Stimmt, ich erkenne sie auch als angehender Dipl. Inf ganz gut, aber lies doch mal bitte was ich schreibe . Ich habe im dcraw-Sourcecode nichts gefunden, was so eine Information auch auswerten würde, und hatte deshalb erwartet, trotzdem ein untransformiertes 16-Bit-Bild herauszubekommen. Ansonsten stimme ich deinen Aussagen voll zu. Ein nettes Beispiel ist übrigens noch, einen aus Versehen auf kaltes Licht gestellten Weißabgleich (Blitz, bewölkter Tag) nachträglich nach Glühlampe zu wandeln oder umgekehrt. Das ist ohne mehr als 8 Bits selten möglich. @hverheyen: Genau nach dem "die Verarbeitung der Kamera ist nicht leistungsfähig genug" sieht es aber leider aus. Link to post Share on other sites More sharing options...
Advertisement Posted December 19, 2006 Posted December 19, 2006 Hi ennjott, Take a look here Eine Frage der Kommunikation .... I'm sure you'll find what you were looking for!
Guest Arias Posted December 19, 2006 Share #162 Posted December 19, 2006 Theoretisch kann ich schon lange nicht mehr folgen, weil mir euer Hintergrundwissen fehlt. Aus meiner Praktikersicht finde ich eure Herangehensweise aber reichlich schräg: Ihr vergrabt euch in bergeweise Datenblätter und schließt aus Tabellen auf eine bestimmte Qualität bzw. bestimmte Mängel der Bilder. Sollte es nicht eigentlich umgekehrt sein? Gruß H. Link to post Share on other sites More sharing options...
augenschmaus Posted December 19, 2006 Share #163 Posted December 19, 2006 @ ennjott - Das Innenleben von Raw-Convertern übersteigt meine Kenntnisse. Es könnte aber doch sehr gut sein, dass in dcraw einfach nicht alle Features des DNG-Formates unterstützt werden. Meinem Verständnis nach dienen die Angaben in der Linearisierungs-Tabelle dazu, die nicht-lineare Transformation, die in der M8 vor dem Speichern stattgefunden hat (Leicas Quadratwurzel) erstmal rückgängig zu machen, damit die Daten wieder linear zur Verfügung stehen und dann auf sie eine "ordentliche" Gammakurve angewandt werden kann. Da diese Quadratwurzel-Abbildung einer flachen Gammakurve ähnlich sieht, könnte ohne diese vorherige Linearisierung im Raw-Converter der Eindruck entstehen, dass schon eine leichte Gammakorrektur bei dem Bild stattgefunden hat. Wenn das Unsinn ist, bitte korrigieren. Link to post Share on other sites More sharing options...
ennjott Posted December 19, 2006 Share #164 Posted December 19, 2006 Stimmt schon, aber der Witz ist ja, daß die dcraw-Ausgabe eben doch linear aussieht. Ich habe eben eine Mail an den Autor geschrieben, aber es wohl nun schon selbst gefunden: Zeile 4103, Funktion linear_table, ein kleiner Fünfzeiler. Wird aufgerufen von der Funktion, die TIFF IFDs liest: "TIFF uses an extendable structure called IFD, which stands for Image File Directory." DNG ist an TIFF angelehnt, die Erkennung von DNG erfolgt anscheinend durch das Lesen des IFD. Ich könnte diese Behandlung mal lahmlegen und dann schauen, was unverändert aus dem Raw herauskommt. @Arias: Wenig Spielraum für Veränderung zu haben ist eine einfache Tatsache, dafür brauch ich mich nirgendwo drin zu vergraben. Will das hier nur verdeutlichen. Man braucht eigentlich nicht mehr zu wissen, als daß ein derart datenreduziertes DNG kein wirkliches "digitales Negativ" ist sondern eher in Richtung Abzug geht. Und von Film-Pushentwicklung usw. habt ihr doch hier sicher weit mehr Ahnung als ich. Link to post Share on other sites More sharing options...
drahthaar Posted December 19, 2006 Share #165 Posted December 19, 2006 (...) Man braucht eigentlich nicht mehr zu wissen, als daß ein derart datenreduziertes DNG kein wirkliches "digitales Negativ" ist sondern eher in Richtung Abzug geht. (...) Nach allem, was ich hier lesend verarbeitet habe, ist das sehr schön auf den Punkt gebracht. Allerdings würde ich sagen, dass ein derart datenreduziertes DNG ein gutes "digitales Negativ" sein kann, aber meistens kein sehr gutes. BG Rolf Link to post Share on other sites More sharing options...
feuervogel69 Posted December 20, 2006 Share #166 Posted December 20, 2006 so langsam versteh ichs jetzt auch. echt toller thread, der mal einblick in die sache gewährt! und wo man versteht, was der unterschied zwischen den in der LFI "nicht erkennbaren unterschieden" (8 versus 16bit) und dem praxisorientierten arbeiten ist, bzw. jetzt habe ich ein gefühl dafür, wo mir die 16 bit fehlen könnten und was daraus resultiert . im prinzip kann man jetzt nur hoffen (fordern??) daß leica per menüumschaltung eine reale 16bit datenspeicherung zuläßt. ohne die leistungen der solmser entwickler schmälern zu wollen, aber DAß wäre sozusagen heute "stand der technik"... unabhängig von der m8 helfen solche threads einfach hinter die kulissen zu schauen. bezüglich der sd10 gehts im dslr-forum auch drum daß z.b. ein weißabgleich nicht unbedingt egal ist (im hinblick auf spätere korrektur im konverter). summa summarum die praxis immer etwas anders ist, als man das theoretisch "weiß gemacht " bekommt. "internas" der signalverarbeitung werden logischerweise nicht auf dem silbertablett präsentiert, umso wertvoller ist die möglichkeit hier etwas einblick zu erhalten, um solche berichte wie in der lfi richtig zuordnen und interpretieren zu können. im prinzip sind die 8bit der m8 kein beinbruch, aber allles was mit feinsten oder sehr hellen lichtern zu tun hat: schnee, wolken, wasser, weiße wände, glas, lichtpunkte+reflexe setzt überlegte belichtung, sorgfältigen weißabgleich und notfalls bracketing voraus. ist doch gut zu wissen, worauf man achten muß. danke dafür an alle fachkräfte. lg matthias Link to post Share on other sites More sharing options...
augenschmaus Posted December 20, 2006 Share #167 Posted December 20, 2006 Advertisement (gone after registration) Stimmt schon, aber der Witz ist ja, daß die dcraw-Ausgabe eben doch linear aussieht.Ich habe eben eine Mail an den Autor geschrieben, aber es wohl nun schon selbst gefunden: Zeile 4103, Funktion linear_table, ein kleiner Fünfzeiler. Wird aufgerufen von der Funktion, die TIFF IFDs liest: "TIFF uses an extendable structure called IFD, which stands for Image File Directory." DNG ist an TIFF angelehnt, die Erkennung von DNG erfolgt anscheinend durch das Lesen des IFD. Sorry, dass ich vorher an Dir mehrmals vorbeigeredet habe - dcraw ist mir fremd, im Sourcecode kramen auch. Da habe ich einfach zur Entspannung was Verwandtes erzählt . Aber jetzt ist die Sache ja offenbar klar. -> Wolltest Du mit den Bildern der nächtlichen Schiffe mehr zeigen als den Unterschied zwischen linear und gamma-korrigiert? Wenn ja, ist es für mich bis jetzt nicht greifbar ... Link to post Share on other sites More sharing options...
Enoteca Posted December 20, 2006 Share #168 Posted December 20, 2006 Der Kölsche Jong würde sagen: 16 Bit? Dat is för misch persönlich uninteressant. BG Rolf (made in Düsseldorf) Seit wann darf denn ein Düsseldorfer Kölle interpretieren? Link to post Share on other sites More sharing options...
Guest chris_h Posted December 20, 2006 Share #169 Posted December 20, 2006 Da diese Quadratwurzel-Abbildung einer flachen Gammakurve ähnlich sieht, könnte ohne diese vorherige Linearisierung im Raw-Converter der Eindruck entstehen, dass schon eine leichte Gammakorrektur bei dem Bild stattgefunden hat. Wenn das Unsinn ist, bitte korrigieren. Das ist nicht nur kein falscher Eindruck, sondern das steht so auch (im LFI) geschrieben ... Wenn ich's nicht ganz falsch verstanden hab', dann entzündet sich daran auch die Hauptkritik: Weil der Eindruck entsteht, man hat diese Methode NUR dazu gewählt, um Speicherplatz zu sparen bzw. die Kamera schneller zu machen; aber eben nicht um die Bildqualität schon an der "Wurzel" zu verbessern. Genau hier setzten auch meine Fragestellungen an - wo ich meine, auch einen interessanten Ansatz für eine prinzipielle qualitative Bildoptimierung zu sehen. Aber vielleicht dann doch nicht auf 8-Bit-, sondern auf 16-Bit-Basis ...!? Link to post Share on other sites More sharing options...
ptomsu Posted December 20, 2006 Share #170 Posted December 20, 2006 Nun sind wir nach vielen Runden wieder dort angekommen, wo eigentlich der Wurm steckt - bei aller Kompaktheit und ähnlichen Requirements scheint leider die Leistungsfähigkeit der M8 Signalverarbeitung stark gelitten zu haben (Prozessorleistung, Schreibgeschwindigkeit, interner schneller Buffer). Daher versucht man durch verschiedene Maßnahmen die Datenflut zu begrenzen um die Kamera trotzdem hinlänglich schnell zu machen. Daher uch ds Wurzelziehen und die 8Bit. DNG ist daran nicht schuld, das kann nämlich bis 32Bit Farbtiefe und auch andere Hersteller die DNG nicht verwenden produzieren bereits heute bis zu 24Bit Farbtiefe bei 16MP (wieder mal Canon, siehe http://www.canon-europe.com/For_Home/Product_Finder/Cameras/Digital_SLR/EOS_1Ds_markII/index.asp?ComponentID=230304&SourcePageID=164046#1) und das noch mit dr mittlerweile bereits 2 Jahre alten DIGIC2 Technologie, die ab der nächsten PMA der DIGIC3 weichen wird, die dann noch schneller ist. Soll jetzt nicht heißen, daß sich eine M8 in irgend einer Weise an diesen Kameras orientieren sollte, das ist sicher nicht gewünscht, allerdings sollten wir uns schin bewußt sein, wo heutige Spitzentechnologie in der Prozessorleistung und Bildverrbeitung liegt und wo daher hier eine M8 einzuordnen ist. Ganz verstehe ich aus der Sicht die wir als interessierte Benutzer einer M8 haben können nicht, warum man bei der Elektronik nicht mit anderen Partnern arbeiten kann, die in der Lage sind potentere Lösungen aud die beine zu stellen. Peter Link to post Share on other sites More sharing options...
Guest chris_h Posted December 20, 2006 Share #171 Posted December 20, 2006 DNG ist daran nicht schuld, das kann nämlich bis 32Bit Farbtiefe und auch andere Hersteller die DNG nicht verwenden produzieren bereits heute bis zu 24Bit Farbtiefe bei 16MP Äh, Peter, 8 Bit je Farbe = 8+8+8 = 24 Bit Farbtiefe ... bei 16 Bit wären's 48 Bit Farbtiefe. Intern arbetet Canon aber mit 12 Bit. Link to post Share on other sites More sharing options...
olaff Posted December 20, 2006 Share #172 Posted December 20, 2006 Äh, Peter, 8 Bit je Farbe = 8+8+8 = 24 Bit Farbtiefe ... bei 16 Bit wären's 48 Bit Farbtiefe.Intern arbetet Canon aber mit 12 Bit. wo steht das eigenlich geschrieben? aus dem cmos machen sie sonst nämlich ein großes geheimnis, nirgends liest man etwas über den tatsächlich fillfaktor, weshalb sich immer eine riesen angriffsfläche bot. habe mich immer gefragt weshalb da C nicht einfach fakten schafft. Link to post Share on other sites More sharing options...
ptomsu Posted December 20, 2006 Share #173 Posted December 20, 2006 Äh, Peter, 8 Bit je Farbe = 8+8+8 = 24 Bit Farbtiefe ... bei 16 Bit wären's 48 Bit Farbtiefe.Intern arbetet Canon aber mit 12 Bit. Chris wenn das die Rechenweise ist, dann ist das Bauernfängerei! Freilich ist 8+8+8=24, aber pro Farbkanal sind das eben nur 8 Bit !!! Ich würde verstehen wollen, daß sich die Farbtiefe immer auf einen Kanal bezieht, also wenn jemand von 16 Bit spricht, dann sollten das 16 Bit pro Kanal sein. Das erinnert mich an die Paketdurchsatzzahlen, die bei Routern und Switches immer ähnlich bauernfängerisch angegeben werden. Scheinbar arbei,tet die gesamte Industrie so :-(( Peter Link to post Share on other sites More sharing options...
Guest chris_h Posted December 20, 2006 Share #174 Posted December 20, 2006 Bislang hab' ich's eher als üblich erlebt, daß man die Bitraten entweder mit jener pro Farbkanal, oder halt bezogen auf die Gesamtfarbtiefe angibt - das ist kein so großes Spezifikum bei Canon allein, aber genau lesen muß man halt. Und mit mehr als 16 Bit arbeitet bislang eh keiner (wenn man von Pentax' 22 Bit absieht - die ich aber auch mal auf Plausibilität abklopfen würde). Link to post Share on other sites More sharing options...
Guest chris_h Posted December 20, 2006 Share #175 Posted December 20, 2006 wo steht das eigenlich geschrieben? aus dem cmos machen sie sonst nämlich ein großes geheimnis, nirgends liest man etwas über den tatsächlich fillfaktor, weshalb sich immer eine riesen angriffsfläche bot. habe mich immer gefragt weshalb da C nicht einfach fakten schafft. Friederich, es wird dich beruhigen, daß auch deine Pentax nur mit Wasser kocht - auch wenn sie das Wasser offensichtlich (im übertragenen Sinne) nicht per Heizstab erwärmen, sondern einen Uranbrennstab reinhängen ... Also, so konkret wie halt möglich, von deren Homepage: 8 Bit (Jpeg), 12 Bit (RAW) und 22 Bit (intern) ... was immer damit erreicht werden soll. Link to post Share on other sites More sharing options...
hverheyen Posted December 20, 2006 Share #176 Posted December 20, 2006 Also, so konkret wie halt möglich, von deren Homepage: 8 Bit (Jpeg), 12 Bit (RAW) und 22 Bit (intern) ... was immer damit erreicht werden soll. M8 = 8 Bit Jpeg, 8 Bit (compressed) DNG, 14/16-Bit intern... was erreicht man damit Link to post Share on other sites More sharing options...
Guest chris_h Posted December 20, 2006 Share #177 Posted December 20, 2006 Ich mein' nur, daß man mehr als aus der Fülle nicht schöpfen kann ... daß ich für 12 Bit technisch 16 Bit im Hintergrund brauche, ist mir ja noch erklärlich - aber 22 Bit ? Und wenn schon, warum nicht gleich "runde" 24 ?! Link to post Share on other sites More sharing options...
mjh Posted December 20, 2006 Share #178 Posted December 20, 2006 wenn das die Rechenweise ist, dann ist das Bauernfängerei! In dieser Passage bezieht sich Canon auf TIFFs – schreibt, daß 16,7-Megapixel-TIFFs 50 Megabyte groß wären und eine Farbtiefe von 24 Bit hätten. Das wären drei Byte pro Pixel und 16,7 mal 3 sind 50,1; das käme also hin. Von der Auflösung des A/D-Wandlers oder der Zahl der Bits pro Pixel in der Raw-Datei ist an dieser Stelle nicht die Rede. Link to post Share on other sites More sharing options...
hverheyen Posted December 20, 2006 Share #179 Posted December 20, 2006 Ich mein' nur, daß man mehr als aus der Fülle nicht schöpfen kann ... daß ich für 12 Bit technisch 16 Bit im Hintergrund brauche, ist mir ja noch erklärlich - aber 22 Bit ? Und wenn schon, warum nicht gleich "runde" 24 ?! wenn es denn stimmt... der Sensor kann möglicherweise mit 22 Bit pro Kanal ausgelesen werden. Oder zumindest kann es der AD-Wandler und ist deshalb mit notwendigen Reserven zum Rauschanteil ausgelegt. Wie es dann weiterverarbeitet wird, erschliesst sich mir nicht. Möglicherweise auf 24 Bit aufblähen und dann komprimieren. Ggf analog so wie bei der M8??? Oder ganz profan den Sensor mit 16 bit auslesen und in der Werbung vom Potenzial des Wandler reden - hört sich halt gut an. Oder oder, kann sowieso kaum jemand nachvollziehen. Link to post Share on other sites More sharing options...
hverheyen Posted December 20, 2006 Share #180 Posted December 20, 2006 Und damit sind wir eigentlich wieder beim ursprünglichen Thema - Kommunikation. Link to post Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.