Wie werden RAW-RGB-10-Bit-Daten komprimiert?

Dies mag wie eine allgemeine Frage erscheinen, auf die ich jedoch keine Antwort finden konnte. Insbesondere verwende ich einen CMOS-Bildsensor , der die folgenden allgemeinen Fähigkeiten hat:

  • Array-Größe: 1280 x 1024 (SXGA), kann auch 640 x 480 (VGA) aufnehmen
  • Ausgabeformate (10 Bit): RGB-Rohdaten

Wenn ich ein SXGA (1280 x 870) nehme, speichere ich die Datei (pragmatisch) mit einer .RAW-Erweiterung. Die Dateigröße beträgt ca. 1000 KB. Wenn ich ein VGA (640 x 480) nehme, beträgt die Größe etwa 300 KB.

Werden sie bereits als "komprimiert" betrachtet? Ist es möglich, diese auf eine kleinere Größe zu komprimieren (sowohl verlustfreies TIFF als auch möglicherweise verlustbehaftetes JPEG)?

Bisher bin ich davon überzeugt, dass die Bilder, die ich aufnehme, kein bestimmtes Format haben und als Raw-Bitmap betrachtet werden . Liege ich falsch?

Referenzen, um mein Ziel zu erreichen, werden sehr geschätzt.

Was ist Ihr Gesamtziel? Werden die Bilddaten wissenschaftlich ausgewertet oder dienen sie ausschließlich Anzeigezwecken? Wie Sie in einem anderen Kommentar erklärt haben, ist die Übertragungszeit in einer Umgebung mit begrenzter Bandbreite von entscheidender Bedeutung, daher sollten Sie sich darüber klarer sein.
Beide. Es muss also keine 100%ige Auflösung oder Definition sein. Ich suche eine gute Qualität mit reduzierter Übertragungszeit, ich versuche, ein Gleichgewicht zwischen beidem herzustellen.
Einfach die Dateien zippen.
Die verlustfreie Komprimierung allgemeiner Daten ist über Zip und viele andere Routinen möglich. Das Ausmaß der möglichen Komprimierung hängt von der in den Daten vorhandenen Entropie ab. Da Sie zusätzliches Wissen haben: dass die Daten ein Bild (Farbe?) Sind, kann dies helfen, eine optimalere verlustfreie Codierung zu finden. Tiff bietet Zip-Komprimierung (und möglicherweise andere, da es sich um ein offenes, erweiterbares Format handelt). jpeg2000 und andere Formate bieten eine verlustfreie Bildkomprimierung, die möglicherweise besser abschneidet als zip
FWIW, Die Dateiklasse "Raw Bitmap", auf die Ihr Link verweist, unterscheidet sich von den "RAW"-Bildern, die auf dieser Site besprochen werden. Ein Einchip-Farbbildsensor zeichnet nicht für jedes Pixel RGB-Werte auf. Es zeichnet nur Rot für einige Pixel auf, nur Grün für einige und nur Blau für andere. Ein RAW-Bild von einer Kamera enthält nichts als diese einzelnen, einfarbigen Pixelwerte. Der Prozess der Umwandlung in ein RGB-Bild wird als „Demosaikierung“ bezeichnet. Ich denke, dass die Kamera, die Sie verwenden, das Demosaikieren für Sie übernimmt und Ihnen dann das RGB-Bild als "rohe Bitmap" liefert.
@SolomonSlow Ich glaube nicht, dass es das Demosaicing macht, denn wenn ich es mit MATLAB in JPEG konvertiere, erscheint es grau, aber wenn ich es demosaikiere und dann konvertiere, wird es bunt
Hoppla! Das Datenblatt habe ich nicht wirklich gelesen. Ich ging davon aus, dass Sie davon gesprochen haben, Bilder unterschiedlicher Größe von der Kamera zu erhalten. Das bedeutet oft eine Ausgabe ohne Mosaik, aber laut Datenblatt sind sogar die kleineren Bilder dieser Kamera wirklich im RAW-Format.
@Sarahcartenz Was verwenden Sie, um sich mit dem Sensor zu verbinden und Daten von ihm abzurufen? Was fotografieren Sie? Was ist Ihr „Ziel“?
@ SolomonSlow Es ist komplexer als das. Die "roten" Filter lassen etwas grünes und blaues Licht durch und umgekehrt. Es wird alles als ein einziger Helligkeitswert gemessen. Die Farbe der "roten" Filter ist selten, wenn überhaupt, die gleiche Farbe wie "Rot" in unseren RGB-Ausgabegeräten. Dito für "G" und "B".
@xiota Technisch gesehen verwende ich eine Kamera, die einen PIC-Mikrocontroller und einen Speicherpuffer verwendet, um die Bilddaten vom oben beschriebenen Sensor abzurufen. Dann verwende ich UART-Kommunikation, um das Bild über einen Puffer in mein Dateisystem zu bekommen. Mein Ziel ist es, diese RAW-Daten zu komprimieren, damit ich sie per Luft übertragen kann. Beantwortet dies die Frage?
@MichaelC, ich hatte nicht die Absicht, eine Diskussion über die Mathematik des Demosaikierens zu eröffnen. Ich wollte nur darauf aufmerksam machen, dass jedes Pixel einer RAW-Datei nur einen Wert hat, der einen von drei möglichen Farbwerten darstellt, während eine typischere Farbbilddatei drei Farbwerte pro Pixel hat (oder dekodiert werden kann, um diese zu ergeben).
@xiota Ich fotografiere die Natur, der Zweck ist die Anzeige, keine weitere Verarbeitung, nur das Betrachten.
@SolomonSlow Aber der sehr wichtige Punkt ist, dass Rohdaten keine Farbwerte haben. Es hat nur Helligkeitswerte. Jeder „Pixelwell“ erfasst Helligkeitswerte aus einem breiten Wellenlängenbereich. Die durch jeden Farbfilter zugelassenen Wellenlängen überlappen sich erheblich mit den durch die anderen beiden Filter zugelassenen Wellenlängen, genau wie die Wellenlängen, für die jeder Zapfentyp in unserer Netzhaut empfindlich ist. Da die Farben der Filter nicht mit den Farben unserer Farbwiedergabesysteme übereinstimmen, müssen alle drei Werte interpoliert werden.
Zu sagen, dass die "grün" gefilterten Pixel nur für "grün" einen Helligkeitswert aufnehmen, ist grundsätzlich falsch.
@MichaelC, das habe ich nicht gesagt.
@SolomonSlow Sie sagten: „Ein Ein-Chip-Farbbildsensor zeichnet nicht RGB-Werte für jedes Pixel auf. Er zeichnet nur Rot für einige Pixel auf, nur Grün für einige und nur Blau für andere. Ein RAW-Bild von einer Kamera enthält nichts sondern diese einzelnen, einfarbigen Pixelwerte.“ Das ist grundsätzlich falsch. Jeder Sensor zeichnet einen Luminanzwert auf, der etwas Licht aus allen drei Bändern enthält. Aber jeder Sinn reagiert am stärksten auf das Licht, das der Farbe des ihn bedeckenden Filters am nächsten kommt. Die Farbe dieser Filter stimmt nicht mit den Lichtwellenlängen überein, die wir für unsere Farbwiedergabe verwenden...
... Systeme für jedes der emittierten Subpixel "R", "G" und "B" für jedes RGB-Pixel in der Ausgabe.
@MichaelC, ich würde eher "vereinfachend" als "grundsätzlich falsch" sagen. Ich hatte nicht die Absicht, eine Diskussion über die Mathematik des Demosaikierens zu eröffnen. Ich wollte nur auf den strukturellen Unterschied zwischen einem RAW-Bild und einem "normalen" Bild aufmerksam machen. Ich wollte nicht auf Details eingehen, die wahrscheinlich nicht dazu beitragen würden, die ursprüngliche Frage des OP zur Komprimierung von RAW-Daten zu beantworten.
Der „strukturelle Unterschied“ zwischen Sensor-Rohdaten und einem Farbbild besteht darin, dass die Rohdaten nur monochromatische Leuchtdichtewerte für jeden Sensor enthalten. Dies unterscheidet sich grundlegend von jeder Ausgabeform, die Werte für mehrere Farben für jedes Pixel im resultierenden Bild enthält. Zu schlussfolgern, dass Rohbilddaten einen beliebigen Farbwert auf „Pixel“-Ebene (die gemessene Ausgabe eines einzelnen Sensors auf dem Sensor) enthalten, ist höchst irreführend und warum viele nicht einmal ansatzweise verstehen, welche Informationen eine Rohdatei enthält und was es enthält nicht. Es braucht null Mathematik, um das zu verstehen.

Antworten (1)

1280 * 1024 * 10 / 8 = 1638400 Byte.
640 * 480 * 10 / 8 = 384000.

Alles, was kleiner ist, muss komprimiert werden. Insbesondere wenn Sie je nach Bildinhalt unterschiedliche Dateigrößen sehen, wissen Sie, dass eine gewisse Komprimierung stattfindet.

Aber wirklich, wenn Sie etwas mit den Daten machen wollen, müssen Sie das Bildformat sowieso kennen und wenn Sie wissen, wie man es dekodiert, wissen Sie, ob es komprimiert ist oder nicht.

Sobald Sie das decodierte Bild haben, können Sie es in einem beliebigen anderen Format speichern, sei es TIFF oder JPEG.

Sie können natürlich auch versuchen, die Rohdateien zu komprimieren.

Der Grund, warum es auf eine kleinere Größe komprimiert werden muss, liegt darin, dass es, sobald es in einer RAW-Datei gespeichert ist, mit einer begrenzten Bandbreite über die Luft übertragen werden muss und die gesamte andere Verarbeitung im Empfängerteil erfolgt. Eine kleinere Größe ermöglicht es, in kürzerer Zeit zu übertragen, wo Zeit bei dieser Anwendung von entscheidender Bedeutung ist. Kann ich trotzdem ohne Dekodierung komprimieren?
wie gesagt, zippen. (oder jede andere Variante eines universellen Komprimierungsalgorithmus). Per Definition können Sie keine bildspezifischen Algorithmen anwenden, ohne zuerst ein Bild zu erhalten, dh. Dekodierung.
Sie können eine Bilddatei nicht wie eine Textdatei komprimieren. Es funktioniert einfach nicht so.
@ths Wenn Sie es mit "dekodieren" meinen, wie es angezeigt wird, kann ich es in eine BMP-Datei dekodieren. Sie sagen jetzt, dass es sich um BMP handelt, das ich auf etwas Kleineres (wie JPEG) komprimieren kann? Aber als RAW kann ich es nur richtig zippen?
Wir sprechen also nicht von einer Camera Raw-Datei, wir sprechen von Daten direkt von einem Imaging-Chip. In diesem Fall gehört dies nicht hierher, sondern auf den Stapelüberlauf. Das geht weit über „Fotografie“ hinaus und in die Datenverarbeitung.
Rechts. aber das Konvertieren in ein verlustbehaftetes JPEG ist per se keine Komprimierung; es ändert tatsächliche Bilddaten.
Ich habe gerade entdeckt, dass die Funktion (imwrite) in Mathlab ein Bildarray wie meines aufnimmt und es in JPEG konvertiert, wodurch die Größe reduziert wird. Das bedeutet, dass ich das ZIP nicht direkt wie beschrieben brauche. Dies ist jedoch etwas verwirrend. mathworks.com/help/matlab/ref/imwrite.html
@Sarahcartenz Beachten Sie, dass das Konvertieren Ihrer Rohdatei in JPEG ein verlustbehafteter Vorgang ist, sowohl bei der Konvertierung als auch, weil JPEG selbst einen verlustbehafteten Komprimierungsalgorithmus verwendet. Das kann für Ihren Zweck in Ordnung sein oder nicht.
Beachten Sie, dass ein Rohbild von ~ 300 KB für eine 640 x 480-Farbkamera bedeutet, dass Sie vor der JPEG-Komprimierung auch einen Demosaicing-Schritt benötigen. Andernfalls würden Sie ein Graustufen-Bayer-Muster komprimieren, was das am wenigsten Vernünftige ist, was Sie mit JPEG tun können
Kurze Frage, wenn ich eine verlustfreie Komprimierung wie Zip verwende und während der Übertragung einige der Daten verloren gehen oder einige Bits umgedreht werden, können sie immer noch erfolgreich dekomprimiert werden?