Konvertierung nach cRaw

[katz123]

Kann jemand http://fi.wikipedia.org/wiki/Tiedosto:Telefunken_FuBK_test_pattern.svg konvertieren 4.288 x 2.856 Pixel ? Ich möchte damit die Wirkungsweise des Rawkonverters testen.

[alberich]

Man kann nur aus RAW entwickeln nicht "In" konvertieren.

[Blitz Blank]

Natürlich kann man Bilddaten in cRAW konvertieren, das Format ist schließlich bekannt (liegt eigentlich auf der Hand, wenn es Konverter im Quelltest gibt, oder?)

Mir ist keine SW bekannt, die diese Richtung umsetzt aber die dcraw Quellen wären ein erster Startpunkt für den Fall, daß man die cRAW Komprimierung tatsächlich selber implementieren muß.

Da cRAW verlustbehaftet ist besteht bei einem solchen Testbild allerdings bereits die Möglichkeit von Verlusten, die eine Beurteilung der RAW-Konverter Umsetzung von cRAW in z.B. TIFF nur noch eingeschränkt erlaubt.
Außerdem ist ohne nähere Beschäftigung mit dem Thema nicht von vornherein klar, ob man den Kamera-RAW Algorithmus tatsächlich exakt nachbilden kann, für alle praktisch relevanten Untersuchungen sollte das allerdings reichen.

Was genau soll eigentlich das Ziel dieses Tests sein?

Frank

[alberich]

Natürlich kann man Bilddaten in cRAW konvertieren, das Format ist schließlich bekannt (liegt eigentlich auf der Hand, wenn es Konverter im Quelltest gibt, oder?)


Nur weil man sie lesen kann, kann man sie noch lange nicht schreiben.
Und nur weil es eventuell rein technisch möglich sei, gibt es am Markt dennoch keine Lösung.

[Blitz Blank]

Nur weil man sie lesen kann, kann man sie noch lange nicht schreiben.
Und nur weil es eventuell rein technisch möglich sei, gibt es am Markt dennoch keine Lösung.

Zunächst mal habt ihr behauptet, daß so etwas gar nicht möglich sei, was schlicht nicht stimmt.
Und mit Programmierkenntnissen kann man so etwas selber entwickeln, dazu braucht es keinen Chuck Norris.

Sollte es dafür bisher keine Lösung am Markt geben stellt sich mir allerdings erst mal die Frage nach dem Sinn des Aufwands.

Frank

[alberich]

Es ist doch alles ganz einfach.
Kannst Du dem Beitragsersteller eine Lösung anbieten für sein Problem?
Sieht nicht danach aus.
Stattdessen ergehst Du dich in eventuellen Lösungen, die irgendwie wohl möglich sein könnten oder auch nicht so exakt, aber doch schon, obgleich Du dann doch erst einmal die Frage nach dem Sinn, respektive der exakten Aufgabenstellung stellen möchtest usw usw. blabla
Das ist doch brotloses Gerede und hilft dem Beitragsersteller überhaupt nicht weiter.
Wenn es Dir aber gut tun sollte, "Ja! Du hast es bemerkt, dass da Zwei etwas, Deiner Ansicht nach, falsches behauptet haben und das zudem öffentlich und in fahrlässiger Weise.

Das hast Du gut gemacht und Danke, dass Du hier für Klarheit gesorgt hast.

[Dat Ei]

Zunächst mal habt ihr behauptet, daß so etwas gar nicht möglich sei, was schlicht nicht stimmt.
Und mit Programmierkenntnissen kann man so etwas selber entwickeln, dazu braucht es keinen Chuck Norris.

Naja, naja.

Die Qualität eines Negativs, das Du aus einem Abzug machst, ist nicht die gleiche, wie die des Originalnegativs. Machen kann man viel, aber eine RAW-Datei heißt RAW, weil sie die originären Sensordaten enthält und nicht Daten, die aus einem gerenderten jpg oder sonstwas abgeleitet wurden.


Dat Ei

[Neonsquare]

Das Zauberwort heißt bijektive Abbildung bzw. ein Isomorphismus. Das liegt in diesem Fall in mehrfacher Hinsicht nicht vor. Sogar die Abbildung RAW->RGB ist nicht eindeutig und noch dazu unvollständig. Die ständige Wiederholung dass cRAW "verlustbehaftet" sei ist deshalb auch ein Schenkelklopfer, wenn man die RAW-Konvertierung ins Spiel nimmt.

Kurz und schmerzlos: ja man kann aus einem RGB-Bild irgendein Bayermuster generieren und dieses per cRAW komprimieren. Das Resultat hat jedoch nichts mit der Realität gemein und ist schlicht nutzlos.

Ergänzung: Es ist generell hilfreich, wenn man beginnt zu begreifen, dass RAW-Daten statistische Messdaten sind, die aus einem physikalischen Prozess entstehen. Da ist nichts exaktes gegeben. Die Variation einzelner Werte ist unwichtig gegenüber der Korrelation aller Werte.

[JoZ]

Da das Original ein .svg, also unkomprimiert ist, müsste eine Umwandlung theoretisch gehen, aber man vermutlich nur mit zusätzlichen Annahmen (was der Sensor aus dem Bild machen würde...).

Es gibt aber eine wesentlich einfachere Art der Umwandlung:

Das svg-Bild groß genug und in geeigneter Qualität ausdrucken und dann abfotografieren.
Dann gibt es sogar "echte" RAW-Daten, mit denen beliebig gespielt werden kann :D :top:

Edit:
Als Neonsquare seinen Beitrag postete, war ich schon beim schreiben, daher jetzt der Nachtrag:
Es gibt durchaus Fälle, wo es Sinn macht, zu Testzwecken Messdaten zu "simulieren", also künstlich zu erzeugen. So wäre das hier sicherlich auch möglich, wenn das Procedere bekannt wäre. Ob es hier Sinn machen würde, wage ich auch zu bezweifeln, aber man weiß ja nie ...

[Blitz Blank]

Es ist doch alles ganz einfach.

Alberich, wenn Du technisch nichts beitragen kannst oder willst... an dieser Stelle verabschieden wir uns von den Nichtschwimmern.

Es hat mal jemand just for fun den "rawnalyzer" geschrieben, ja, es gibt Leute, die Spaß daran haben und in der Lage sind, sich mit den technischen Hintergründen auseinanderzusetzen.

Die Qualität eines Negativs, das Du aus einem Abzug machst, ist nicht die gleiche, wie die des Originalnegativs. Machen kann man viel, aber eine RAW-Datei heißt RAW, weil sie die originären Sensordaten enthält und nicht Daten, die aus einem gerenderten jpg oder sonstwas abgeleitet wurden.


Jein. Wenn man diese Diskussion sinnvoll führen will muß man es genau nehmen. Ausgangsmaterial ist ein SVG, also eine Vektorgrafik (die Pixelgrafik enthalten mag, so genau habe ich sie mir nicht angesehen).
Das heißt:
- sie ist auflösungsmäßig nicht begrenzt
- sie enthält keine Kompressionsartefakte
Und ist damit etwas ganz anderes als ein JPEG, nämlich ideales Ausgangsmaterial.

Sie wird beim Sampling auf eine Zielgröße, also die Auflösung des Sensors, entsprechende Artefakte wie Aliasing zeigen. Ein idealer Sensor hätte mit idealem Objektiv und ohne AA Filter aber ein ähnliches Bild erzeugt.
Die gesamte Fragestellung ist bisher auf Genauigkeit angelegt, sonst ist eine Untersuchung der RAW-Konvertierung anhand solcher idealer Vorlagen jedenfalls von vornherein kaum sinnvoll. Dann nimmt man ein Testtafel-cRAW und gut ist's.

Da katz schon einige Jahre dabei ist und über eine gute Ausrüstung verfügt gehe ich jedoch erstmal davon aus, daß die Frage so gemeint ist wie sie gestellt wurde.

Frank

[Blitz Blank]

Das Zauberwort heißt bijektive Abbildung bzw. ein Isomorphismus. Das liegt in diesem Fall in mehrfacher Hinsicht nicht vor.


Richtig, das stellt aber nicht die Umsetzbarkeit einer nah-genug-dran Lösung in Frage.


Sogar die Abbildung RAW->RGB ist nicht eindeutig und noch dazu unvollständig.


Nicht eindeutig ist klar aber wieso unvollständig?


Kurz und schmerzlos: ja man kann aus einem RGB-Bild irgendein Bayermuster generieren und dieses per cRAW komprimieren. Das Resultat hat jedoch nichts mit der Realität gemein und ist schlicht nutzlos.


Der Rückweg zeigt eine idealisierte (und damit abweichende) Verarbeitungskette aber ob das nutzlos ist kann erst ein Versuch zeigen.
Bis dahin haben wir bislang nur zwei Arbeitshypothesen.


Die Variation einzelner Werte ist unwichtig gegenüber der Korrelation aller Werte.

Die Korrelation ist der Algorithmus, ansonsten ist der statistische Teil bereits erledigt, wenn die Kamera die RAW-Daten ausgibt, zuzüglich der weiteren Verarbeitungskette durch den Konverter.

Vielleicht sollten wir kurz Katz zu Wort kommen lassen bevor wir uns hier weiter die Köpfe heiß diskutieren :-)

Frank

[Neonsquare]

Richtig, das stellt aber nicht die Umsetzbarkeit einer nah-genug-dran Lösung in Frage.


Nah genug dran an was? Da ist ja nur ein X und wenn das konkretisiert wird, ist die gesamte Geschichte bagatellisiert und phänomenal unwichtig.


Nicht eindeutig ist klar aber wieso unvollständig?


RAW->RGB ist interpoliert. Der Algorithmus dazu kann beliebig sein und er ist nicht Teil des Formats, sondern Teil des Prozesses. Im Zielraum hast Du unzählige Punkte, die lediglich algorithmisch bedingt sind, welche Du aber nicht als solche erkennen kannst. Ganz primitiv: Du kannst nicht aus einer Fläche berechnen, wie die exakten Seitenlängen des zugehörigen Rechtecks waren.


Der Rückweg zeigt eine idealisierte (und damit abweichende) Verarbeitungskette aber ob das nutzlos ist kann erst ein Versuch zeigen.
Bis dahin haben wir bislang nur zwei Arbeitshypothesen.


Nuff'said: damit das funktioniert, muss er sämtliche Details und Annahmen des Algorithmus spezifizieren. Danach braucht er aber nichts mehr analysieren, denn er hat die Spezifikation ja selbst geschrieben. Das ist so wie wenn der Schüler sich die Prüfungsfragen selbst ausdenken darf. Ebenso aussagekräftig ist dann das Resultat.

[Dat Ei]

Moin Frank,

Jein. Wenn man diese Diskussion sinnvoll führen will muß man es genau nehmen. Ausgangsmaterial ist ein SVG, also eine Vektorgrafik (die Pixelgrafik enthalten mag, so genau habe ich sie mir nicht angesehen).
Das heißt:
- sie ist auflösungsmäßig nicht begrenzt
- sie enthält keine Kompressionsartefakte
Und ist damit etwas ganz anderes als ein JPEG, nämlich ideales Ausgangsmaterial.

ok, dann nehmen wir es genau. Die Vektorgrafik mag in sich ein ideales Ausgangsmaterial sein, allerdings ist jede Form von Konvertierung in eine Ausgabe nicht mehr ideal. Da die Auflösung eines jeden Zielformates endlich ist, wird der Rendering-Prozess immer kompromissbehaftet sein. Der Algorithmus des Renderings prägt das Ergebnis.

Von daher ist es egal, ob nun erst in ein darstellbares, pixelorientiertes Grafikformat oder gleich in das "nicht darstellbare Kunstprodukt" RAW-Datei gerendert wird. Eine Konvertierung von RAW in ein sichtbares Format erzeugt kein dezidiertes Ergebnis - darüber sind sich wohl alle einig. Für den umgekehrten Weg gilt selbiges.


Dat Ei