Unterschiedliche Dateigröße bei Raw-Files - Wieso?

[Gast_169861]

AW: Re: Unterschiedliche Dateigröße bei Rohdateien — wieso?

Auch ohne kleinen Japaner im Compi...

Ärgere Dich nicht, das ist der allfällige Umgangston der Halbblinden hier im Forum.

Danke....

Der Algorithmus ist! der kleine Japaner.......und ärgern tue ich mich nicht mehr.

Gruss, Uwe.

 

[burkhard2]

Und da Rohbilddateien vor dem Demosaicing noch keine Bilder darstellen, tue ich mich schwer mit der Vorstellung, dass dann bildoptimierte Kompressionsverfahren angewendet werden können.

Selbstverständlich sind das Bilddaten und haben ganz ähnliche Eigenschaften wie die des Bildes nach dem Demosaicing (insbesondere haben benachbarte Pixel mit hoher Wahrscheinlichkeit ähnliche Werte). Eine Trennung in YCbCr wie bei JPEG ist natürlich nicht sinnvoll, aber zumindest die Farbebenen einzeln könnte man mit einem JPEG-ähnlichen Verfahren komprimieren.

Beim verlustbehafteten Nikon-Raws werden bei den helleren Tonwerten einfach Zwischenstufen weggelassen, zwischen den Werten 999 und 1000 ist kein sichtbarer Unterschied (da ist der Messfehler durch das Rauschen weit größer).

L.G.

Burkhard.

 

[Gast_169861]

(insbesondere haben benachbarte Pixel mit hoher Wahrscheinlichkeit ähnliche Werte).

Wenn schon dann Sensorelemente. Rawdateien enthalten keine Pixel. Die entstehen erst nach dem Demosaicing.

Gruss, Uwe.

 

[Frank Klemm]

Wenn schon dann Sensorelemente. Rawdateien enthalten keine Pixel. Die entstehen erst nach dem Demosaicing.

Rawdaten enthalten Pixel (häufig Subpixel genannt).
Man kann sie sehr einfach darstellen.

Rote Subpixel rot, grüne Subpixel grün (mit halber Helligkeit), blaue Subpixel blau.
Man erhält ein normal betrachtbares Bild, was nur etwas dunkel ist.

Demosaiking macht das ganze nur etwas besser. Es holt etwas mehr Auflösung raus und erzeugt weniger Artefakte.

Weiterhin sind die Daten siliciumfrei, enthalten keine Atome des Sensors.
Es kommt auch nicht zur Abnutzung des Sensors, weil Sesnorelemente in die Rohdaten abwandern.

 

[Gast_169861]

Man kann sie sehr einfach darstellen.

Gibt es tatsächlich ein Programm, das die Informationen der Rawdatei ohne Demosaicing darstellen kann? Also das man es relativ leicht programmieren könnte ist schon klar, aber gibt es so etwas?
Das würde mich mal interessieren.

Da ein Pixel in z.B. einer jpg Bilddatei nicht das Gleiche ist wie ein Sensorelement finde ich die begriffliche Gleichsetzung führt eher zur Verwirrung. Deswegen gibt es im Englischen den Begriff "Sensel" für Sensorelement als Analogie zum Pixel.

Gruss, Uwe.

 

[turricanus]

Gibt es tatsächlich ein Programm, das die Informationen der Rawdatei ohne Demosaicing darstellen kann? Also das man es relativ leicht programmieren könnte ist schon klar, aber gibt es so etwas?
Das würde mich mal interessieren.

z.B. Rawtherapie http://rawtherapee.com/

Da kann man das Demosaicing ausstellen.

 

[burkhard2]

Gibt es tatsächlich ein Programm, das die Informationen der Rawdatei ohne Demosaicing darstellen kann? Also das man es relativ leicht programmieren könnte ist schon klar, aber gibt es so etwas?
Das würde mich mal interessieren.

dcraw (aber nur als Graustufendatei), PhotoLine (mit zugeordneten Farbwerten).

Da ein Pixel in z.B. einer jpg Bilddatei nicht das Gleiche ist wie ein Sensorelement finde ich die begriffliche Gleichsetzung führt eher zur Verwirrung.

Solange die Kamerahersteller von Pixeln sprechen, finde ich eher die Einführung eines neuen Begriffs ("Sensel") verwirrend. Übrigens haben auch viele JPEG-Dateien 4:2:0-Subsampling, also Farbinformation auch nicht für jedes Pixel einzeln.

L.G.

Burkhard.

 

[01af]

Re: Unterschiedliche Dateigröße bei Rohdateien — wieso?

... daß dann bildoptimierte Kompressionsverfahren angewendet werden können.

Das Wort "bildoptimiert" existiert nur in deinem Kopf. Vergiß es wieder.

 

[Manni1]

Was ich meine ist ganz einfach, dass z.B. ein jpg Algorithmus nur auf Bilder wirkt/wirken kann und nicht auf Texte, Musikdateien oder GPS Daten oder sonst irgendetwas.
Und deswegen spielt der Inhalt der Datei eine Rolle.
Also es muss eine Bilddatei für dieses Verfahren vorliegen.

Nein. Eine Algorithmus kann man auf jede Art von Daten loslassen. Er wird bloß bei Texten, Tabellen, Datenbanken oder was auch immer nix oder wenig an Nutzeffekt - in unsrem Fall Komprimierung - bringen.

Ich versteh nicht auf was Du rauswillst.

 

[turricanus]

Ich glaube ich meine zu wissen wie sich pentuwe sich das vorstellt.

Ein Komprimieralgorithmus arbeitet nicht Inhaltssensitiv auf ein Individuelles, Bild bezogen .
Davon abgesehen haben Bilddateien Gemeinsamkeiten. Ein "spezialisierter" Komprimieralgorithmus nutzt gerade Gegebenheiten in diesen Gemeinsamkeiten aus um ein Bild effektiver komprimieren als zum Beispiel eine Audiodatei.
Theoretisch könnte man ein Bild auch mit dem mp3 Algorithmus komprimieren, am ende würde man aber "defektes" Bild herausbekommen da daten die Audiobereich weggelassen werden können Bildwichtig sein können..

 

[01af]

Re: Unterschiedliche Dateigröße bei Rohdaten — wieso?

Er wird bloß bei Texten, Tabellen, Datenbanken oder was auch immer nix oder wenig an Nutzeffekt – in unsrem Fall Komprimierung – bringen.

Selbstverständlich kann man auch Audiodaten, Texte oder Datenbanktabellen mit dem JPEG-Algorithmus komprimieren. Der Kompressionsgrad wird nur deswegen geringer ausfallen, weil die Redundanz in Nicht-Bild-Dateien von anderer Form ist als in Bilddateien ... nämlich ähnlich wie z. B. in verrauschten Bilddateien, wo das Rauschen ja auch nicht wirklich zum Bildinhalt gehört und die Effektivität der Kompression deutlich reduziert.

Das Hauptproblem aber wäre ein anderes – du würdest die Texte und Tabellen hinterher nicht mehr lesen können. Weil die Verluste der JPEG-Kompression so gestaltet sind, daß sie Bilder nur unwesentlich beeinträchtigen. Andere Daten aber würden durch dieselben Verluste unkenntlich werden.

 

[lichtbildle]

AW: Re: Unterschiedliche Dateigröße bei Rohdaten — wieso?

Selbstverständlich kann man auch Audiodaten, Texte oder Datenbanktabellen mit dem JPEG-Algorithmus komprimieren.

Nein, das geht nicht. Jedenfalls nicht in dem Sinn, daß dann noch etwas irgendwie Brauchbares herauskäme. JPEG gehört wie auch die verschiedenen MPEG-Standards zu den verlustbehafteten Verfahren. Diese darf man nicht verwechseln mit verlustfreien Kompressionsverfahren, wie sie z. B. in ZIP und RAR implementiert sind.

Die verlustbehafteten Verfahren eignen sich nur genau für eine bestimmte Datenart, bei der festgelegt wurde, in welcher Weise Vereinfachungen zulässig sind. Bei JPEG geht das sogar so weit, daß der Standard im engeren Sinn nur einen Algorithmus zur Kompression von Rasterbilddaten definiert und das Dateiformat JFIF (das, was wir als .jpg oder .jpeg kennen) eigentlich einen eigenen Standard darstellt.

Maximale Kompression ist übrigens keineswegs immer das einzige oder auch nur Haupt-Designziel eines Kompressionsalgorithmus. So kann es z. B. wichtig sein, daß sich ein schneller Encoder in einfacher Hardware implementieren läßt oder daß die Decodierung geringen Rechen- und damit Energieaufwand erfordert, oder (leider) auch ganz Untechnisches wie die Umschiffung von Patenten.

 

[turricanus]

AW: Re: Unterschiedliche Dateigröße bei Rohdaten — wieso?

Nein, das geht nicht. JPEG gehört wie auch die verschiedenen MPEG-Standards zu den verlustbehafteten Verfahren.

Prinzipiell kann man natürlich den Algorithmus auf die Daten anwenden ob es Sinnvoll ist steht auf einem anderen Blatt. Das ist die aussage von 01af.

 

[01af]

Re: Unterschiedliche Dateigröße bei Rohdaten — wieso?

... nicht in dem Sinn, daß dann noch etwas irgendwie brauchbares herauskäme.

Liest du eigentlich das, worauf du antwortest?

 

[Gast_169861]

Ich glaube ich meine zu wissen wie sich pentuwe sich das vorstellt.

Ein Komprimieralgorithmus arbeitet nicht Inhaltssensitiv auf ein Individuelles, Bild bezogen .

Und für diese Erkenntnis haben wir jetzt 5 Seiten benötigt.

Das Wort "bildoptimiert" existiert nur in deinem Kopf. Vergiß es wieder.

Selbstverständlich kann man auch Audiodaten, Texte oder Datenbanktabellen mit dem JPEG-Algorithmus komprimieren. Der Kompressionsgrad wird nur deswegen geringer ausfallen, weil die Redundanz in Nicht-Bild-Dateien von anderer Form ist als in Bilddateien

Da widersprichst du dir von einer Seite zur anderen selbst.

Solange die Kamerahersteller von Pixeln sprechen, finde ich eher die Einführung eines neuen Begriffs ("Sensel") verwirrend. Übrigens haben auch viele JPEG-Dateien 4:2:0-Subsampling, also Farbinformation auch nicht für jedes Pixel einzeln.
L.G.

Burkhard.

Deswegen wird es ja nicht besser, das ist halt Werbung.
Aber das Wort ist ja keine Erfindung von mir, sondern wird in der Literatur durchaus verwendet.
Ich verwende es nur gerne, da es den Unterschied eben deutlich macht.

Ansonsten läuft die Diskussion jetzt wieder in einen theoretischen, sinnlosen Zickzackkurs.

Gruss, Uwe.

 

[whr_]

Nein. Eine Algorithmus kann man auf jede Art von Daten loslassen. Er wird bloß bei Texten, Tabellen, Datenbanken oder was auch immer nix oder wenig an Nutzeffekt - in unsrem Fall Komprimierung - bringen.

JPEG umfaßt im wesentlichen zwei Schritte - für den ersten müssen die Daten wenigstens formal ein zweidimensionales Array bilden (im Regelfall ein Bild), das dann in Kacheln aufgeteilt wird, diese DCT-transformiert und nur die niedrigen Fourierkoeffizienten feinstufig, die höheren nur noch sehr grob quantisiert werden. Die Auflösung dieser Quantisierung ist wählbar über einen Qualitätsparameter, und damit auch der Kompressionsgrad. Das Verfahren entfernt angenommene Irrelevanz. Es ist nicht verlustfrei umkehrbar.

Der zweite Schritt reduziert Redundanz durch einen Huffman-Algorithmus. Es ist verlustfrei umkehrbar, der Kompressionsgrad hängt auschließlich von den Daten ab und ist nicht wählbar.

Falsch (s.o.) es gibt eben durchaus kontextorientierte verlustfreie Kompressionsalgorhithmen, die nicht nur einen Algorithmus anwenden, sondern auch kontextspezifische Kenntnisse. Stichwort "FLAC" (Audio Kompression).

Soso, es gibt Algorithmen, die Deiner Meinung nach keine Algorithmen sind?

Es bleibt auch dann ein Algorithmus. Solange das Ergebnis der Kompression nur von den Daten und ggf. extern vorgegebenen Parametern abhängt, aber nicht von Zufall oder menschlichen Entscheidungen, läßt sich diese durch einen Algorithmus beschreiben.

Unter Blinden ist der Einäugige König.

 

[Gast_169861]

Soso, es gibt Algorithmen, die Deiner Meinung nach keine Algorithmen sind?

Das hat er weder geschrieben noch gemeint.
Hier muss wohl alles zwanghaft falsch interpretiert werden.

 

[whr_]

Das hat er weder geschrieben noch gemeint.
Hier muss wohl alles zwanghaft falsch interpretiert werden.

Wer behaupte, meine vorherige Aussage sei falsch, sollte das belegen können. Zu interpretieren ist da nicht viel.

Meine Ausage:

Jedes Kompressionsverfahren wendet "einfach nur einen Algorithmus" an - da sitzt kein kleiner Japaner drin, der nach Bauchgefühl oder Wetterlage entscheidet.

Sein Kommentar unmittelbar darauf (meine Aussage wie oben zitiert):

Falsch (s.o.) es gibt eben durchaus kontextorientierte verlustfreie Kompressionsalgorhithmen, die nicht nur einen Algorithmus anwenden, sondern auch kontextspezifische Kenntnisse. Stichwort "FLAC" (Audio Kompression).

Natürlich hat er geschrieben, es gäbe Kompressionsverfahren, die anderes tun, als einen Algorithmus anzuwenden. Oder sprechen wir unterschiedliche Sprachen?

Und das stimmt nicht.

 

[affot]

Um Himmels Willen!!
Was man mit so einer Frage und einer voreilig, unüberlegt getroffenen Aussage für eine Diskussion entfachen kann

Also die Aussage, dass meine Kamera, bzw. Kameras generell, im Raw nicht komprimiert war anscheinend generell falsch, und darüber hatte ich mir keine Gedanken gemacht.
Sinn macht es so nun allemal, danke für eure Antworten!

 

[Balaleica]

Natürlich hat er geschrieben, es gäbe Kompressionsverfahren, die anderes tun, als einen Algorithmus anzuwenden. Oder sprechen wir unterschiedliche Sprachen?

Interpretation. Folgendes Beispiel: Alte Westwood-Spiele (Eye of Beholder, diverse Adventure-Spiele usw.) hatten Grafikdaten komprimiert. Effektiv wurden dabei 2 Algorithmen zusammengebracht: Einmal RLE (Lauflängen-Kodierung) und zweimal LZ77 mit jeweils unterschiedlichen Fenster-Größen (und dementsprechend unterschiedlichen Bitlängen bei der Kompression). Das kann man jetzt als ein Algorithmus verkaufen oder von einer kontextabhängigen Kombination von mehreren Algorithmen sprechen.