Forum Übersicht - SLT-A99V » SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

Hallo zusammen,

David Kilpatricks ausführlicher Bericht zur SLT-A99

http://www.photoclubalpha.com/2012/12/27/s...ped-in-dilemma/

geht u.a. auf einen Aspekt der Kamera ein, der zwar seit einigen Wochen bei Dyxum diskutiert wird, meiner Erinnerung nach aber außer einer kurzen Erwähnung hier noch gar nicht zur Sprache kam, die Fähigkeit der SLT-A99 nämlich, als erste Alpha-Kamera 14-Bit-Rohdaten zu liefern (gegenüber 12 Bit vorher).

Allerdings leider nicht durchgängig, 14-Bit-RAWs bekommt man ausschließlich nur im Einzelbildbetrieb bzw. mit Single-Bracketing, und auch dann nur solange man nicht mit Langzeitbelichtungsrauschunterdrückung (Long Exposure NR) oder im BULB-Modus arbeitet. In den anderen Betriebsarten (selbst bei langsamen 2,5-Bilder/Sekunde-Serien) schaltet die Kamera immer auf 12 Bit runter. Das ist nicht unbedingt, was man erwartet, auch wenn es zumindest in der Bedienungsanleitung der Kamera erwähnt wird.

Einen weiteren Punkt spricht David ebenfalls an, der Auslösezyklus ist bei der SLT-A99 gegenüber anderen Kameras deutlich verlängert. Möglicherweise wollte Sony hier eine Art "Leise-Modus" (wie hier im Forum öfters gefordert) realisieren - das Geräusch ist seinen Messungen zufolge auch tatsächlich leiser als bei anderen Kameras, nur: dadurch, daß es sehr viel länger anhält und akustisch in zwei einzeln wahrnehmbare Ereignisse zerfällt, fällt es ihm zufolge dennoch deutlicher auf - im Extremfall zieht sich die Geräuschkulisse für einen kompletten Ablauf über 420ms, also fast eine halbe Sekunde lang hin. Die Dunkelphase des Suchers soll sich ihm zufolge im 14-Bit-Betrieb gegenüber dem 12-Bit-Betrieb um etwa 100ms verlängern.

ZITATThe D600 with its complete mirror up and down, twin shutter blind and recock action feels and sounds sweeter than the A99 which has no mirror to move and no first shutter blind. In fact, it's louder and the dB peak for a very brief spike is about twice the volume of the A99 or the A77. But some recording with sound analysis reveals that the A99 sounds ‘louder' because the actual duration of the sound is almost twice as long, and divided into two distinct clunks.
[...]
The D600, like the A77, has a normal single-shot shutter sound of around one sixth of a second, as you would expect from cameras which can achieve 6fps or something close. The Alpha 99 has double that. I timed it at over 300ms, and if first curtain mechanical mode was used, well over 400ms.

It took me a few days and some digging to find out that the 14-bit readout on the A99 only applies one shooting mode - single shot. Any other mode you select, including Lo 2.5fps continuous and all multishot or JPEG only modes, uses 12-bit readout from the sensor. This was already documented in the literature about the A99, but what Sony omit to say is that the 14-bit mode causes a noticeable pause between the shot being captured and the restoration of EVF viewing. This pause is around 1/10th of a second longer in single shot mode than the blackout which happens during 2.5fps or the first frame of any faster sequence, and totals 200ms or 1/5th of a second.
[...]
Thanks to the detailed analysis of audio recording using Amadeus Pro, followed by frame by frame time analysis of an iMac movie clip showing the actual LCD screen blackout period, I have been able to see this ‘dead period' of blackout and image processing is longer than the entire shutter action of the A77 or D600; indeed, the shutter actions of the A99 surround this hiatus. The card writing light comes on a millisecond or two after the live view blacks out. The action of the shutter curtain being recocked, which accounts for a substantial part of the overall shutter noise, only happens at the end of the 1/5th second pause.

Short of a firmware upgrade, there's nothing you can do about the extremely slow single-shot shutter cycle or the interrupted finder view if you want the extra quality which comes from 14-bit raw capture. Nikon offer you a choice of 12 or 14 bit, compressed or uncompressed RAWs. Sony does not offer a choice and makes the bit depth specific to the way you shoot. There is no doubt at all that both RAWs in single-shot mode, and Extra Fine Quality JPEGs created in this mode, show less noise when adjusted to an extreme. 12-bit capture is fine for lower ISOs, in good light, with correct exposure.
[...]
The 3fps Lo motordrive setting was easy to use for single frames, with a light touch. This caused half the finder blackout duration and no more than a 290ms total sound envelope (including all reverberation - the main sound is not unlike the 180ms of the D600 or A77). It didn't matter what file size and type I recorded or what card was used. This setting always produced the shutter cycle, and sound, I would have expected the A99 to have.

Having observed the way the camera works, I'm afraid I am now rather too aware of it. It makes me appreciate the Alpha 77's much faster, sweeter action and even consider the A900's noisy clack with affection. One effect of the longer shutter cycle is to make the relatively quiet sound - 4dB quieter at peak than the Nikon D600 which also has a higher and more intrusive pitch - seem ‘louder' than it actually is.

What is interesting to me is just how few users, when I asked for information or tests of their own cameras, were really able to hear the differences or see the blackout period. I can thank Gary Friedman for being able to confirm my findings - he could understand exactly what I was looking for. And thanks to several posters on Dyxum forums, whose concerns were with the image quality of 14-bit versus 12-bit, for providing the information I need to put the facts together and realise that no amount of adjusting settings was ever going to make the A99 share the brief blackout and sweet shutter sound of the 12-bit A77.[/quote]
Siehe auch:

http://www.photoclubalpha.com/forum/viewto...f=32&t=7228
http://forums.dpreview.com/forums/thread/3...m-post-50364827

Vorteilhaft: Die 14-Bit-Rohdaten enthalten bei der SLT-A99 nicht nur Rauschen, sondern tatsächlich nutzbare Daten, was allerdings nur bei extremen Belichtungssituationen wirklich auffällt. Im folgenden Dyxum-Thread finden sich ein paar Vergleichsbilder:

http://www.dyxum.com/dforum/a99-14-bit-raw...topic93219.html

Viele Grüße,

Matthias

Hallo Matthias,

ich hab noch keine A99 ARW Datei gefunden in der 14 Bit Daten abgelegt sind. Ich kann das deshalb sehr einfach feststellen, weil ich den Quellcode von alten dcraw Versionen hier im Debugger der Entwicklungsumgebung direkt verfolgen kann. Alle bisherigen Dateien laufen im Debugger durch den cRAW dekompressionscode der die komprimierten Daten wieder auf 12 Bit dekomprimiert. Weitere Bits sind da nicht enthalten, denn das würde auch einen anderen Algorithmus erfordern.

Sollte der 14 Bit Modus wirklich die auf dyxum gezeigten Vorteile bringen, so hat das jedenfalls nichts mit dem abspeichern von 14 Bit in den ARW Dateien zu tun, sondern, wie ich vermute mit einer reduzierten "sampling rate" der ADCs und evtl. damit verbundener präziserer Abtastung der Sensordaten.

Ich habe persönlich keine A99, und solange ich nicht die originalen ARWs von z.B. dyxum zu sehen bekomme, habe ich daran erstmal erhebliche Zweifel.

BG Hans

ZITAT(Hans-J. @ 2012-12-30, 19:52) Sollte der 14 Bit Modus wirklich die auf dyxum gezeigten Vorteile bringen, so hat das jedenfalls nichts mit dem abspeichern von 14 Bit in den ARW Dateien zu tun, sondern, wie ich vermute mit einer reduzierten "sampling rate" der ADCs und evtl. damit verbundener präziserer Abtastung der Sensordaten.[/quote]
Danke für Deine Ergänzung und Korrektur! Auch bei Dyxum gibt es ja ein paar Stimmen, die bezweifeln, daß die SLT-A99 ARWs 14 Bit Daten überhaupt enthalten - ich hatte das vorhin nur überflogen und da war mir das noch nicht ins Auge gefallen. Wir sollten das in jedem Fall näher untersuchen - und auch Sonys Werbeaussagen diesbezüglich auf ihren Wahrheitsgehalt abklopfen.

http://www.dyxum.com/dforum/photoclub-alph...08.html#1121308 ff.

http://forums.dpreview.com/forums/thread/3...m-post-39707815
http://forums.dpreview.com/forums/thread/3...m-post-39721763
http://www.sonyuserforum.de/forum/showthread.php?p=1387110
https://club-sonus.sony.de/forum/thread.jspa?threadID=8942
http://www.getdpi.com/forum/sony/42244-fun-rx-1-a-6.html (DSC-RX1)

Viele Grüße,

Matthias

Ich habe im SUF bereits kurz nach erscheinen der A99 ebenfalls mit dcraw.c überprüft ob tatsächlich etwas an den ARW-Daten verändert wurde und habe dasselbe festgestellt wie Hans-J. Damals habe ich auch schon die Vermutung angestellt, dass sich die 14 Bit RAW eher auf die interne Verarbeitung der RAW-Daten im Bionz bezieht und weniger auf die Datenspeicherung als ARW-Datei. Spätestens hier sollte man sich von der romantischen Vorstellung endlich mal lösen, dass die Pixelwerte der RAW-Dateien in irgendeiner Form "rohe Sensordaten" darstellen. Ebenso sollte man sich von der Vorstellung lösen, das es einen direkten Zusammenhang zwischen 12/14 Bit RAW und den 16 Bit/Kanal in Photoshop gibt; Da werden Meter mit Kilogramm verglichen. Die übliche Bitzahl (pro Kanal) der Verarbeitungspipeline eines modernen RAW-Konverters ist 32 oder 64 bit in Gleitkommarepräsentation; erst im allerletzten Schritt werden daraus auf Wunsch 16 Bit / Farbkanal. Bei Aperture beispielsweise tatsächlich erst wenn man ein 16-Bit TIFF oder 16-Bit PSD exportiert. Wenn es nur um das Dateiformat ARW ginge, dann wäre es ein leichtes auch 16 Bit RAW oder mehr zu bewerben ;-).

Ich hab mir gerade mal den aktuellen Quelltext von dcraw angeschaut. Da dieser praktisch keine Kommentare enthält und alles andere als selbstdokumentierend geschrieben ist, habe ich mir die Mühe gemacht, die für uns relevanten Teile zu extrahieren und etwas umzuformatieren, so daß es hoffentlich besser lesbar wird. Im Wesentlichen geht es eigentlich nur um die letzte unten zitierte Routine, d.h. sony_arw2_load_raw() für cRAWs, aber ich habe die alte Routine für nicht komprimierte RAWs und ein bißchen Beiwerk drin gelassen, um ein paar globale Variablen, Makros und Unterroutinen direkt mitzudokumentieren.

Damit andere einen einfacheren Einstieg finden, habe ich die sony_arw2_load_raw() ausführlich kommentiert. Sämtliche //-Kommentare stammen von mir und sind im Originalquelltext nicht zu finden. Eigentlich müßte man für ein besseres Verständnis noch die ganzen als Literale eingestreuten Zahlen symbolisch definieren, um ihre jeweilige Herkunft zu motivieren, aber den Aufwand spare ich mir erstmal.

Die bisherige "Reverse-Engineering"-Analyse erfolgte "trocken", d.h. ohne Entwicklungsumgebung oder passende Raw-Dateien. Zwei Stellen, die sich mir im Moment (noch) nicht erschließen, habe ich mit "DEBUG" markiert.

Im Grunde funktioniert der Algorithmus wie folgt:

In den cRAW-Dateien von Sony gibt es einen kontinuierlichen Bereich, in dem Zeile für Zeile jeweils eine komplette Zeile Rohdaten zu finden sind. Diese Daten sind in Blöcken (Cluster) von jeweils 128 Bit (entsprechend 16 Bytes) angeordnet und jeder dieser Blöcke enthält 16 Rohdatenwerte, die nach einem bestimmten Schema innerhalb dieses Blocks angeordnet sind.
In den ersten 30 Bits, dem Kopf (Header), werden die Werte vierer Konstanten definiert, die für die Dekompression des gesamten Blocks und seine Konvertierung in 16 Rohdatenwerte wichtig sind, max, min, imax und imin (in der Bitmap unten mit a, b, c und d skizziert). max und min sind beides 11-Bit-Werte, die den größten und den kleinsten Wert definieren, der in diesem Cluster von Werten enthalten ist. Welche der 16 Werte damit beschrieben werden, ist nicht festgelegt, dafür dienen genau die beiden folgenden 4-Bit-Werte imax und imin, die jeweils einen Index darstellen, der auf den Wert aus der Menge der 16 zu diesem Block gehörenden Werte zeigt, der in max bzw. min definiert wird. 4 Bit reichen gerade, um 16 mögliche Positionen zu beschreiben. Mit anderen Worten, zwei der 16 Werte sind bereits im Kopf definiert und jeweils 11 Bit breit. Daß man 30 Bit benötigt, um 2*11 Bit zu beschreiben, klingt erstmal nach Verschwendung, aber die Werte werden auch noch für andere Zwecke benötigt.
Wie oben schon beschrieben folgen nach den 30 Bits des Kopfs 128-30 = 98 Bit, die die restlichen 14 Rohdatenwerte beschreiben. Jeder von diesen Werten ist in der Datei mit nur 7 Bits abgelegt. Diese 14 7-Bit-Gruppen werden in aufsteigender Reihenfolge nacheinander den noch freien Slots (zwei sind ja bereits mit dem Maximum und dem Minimum belegt) zugeordnet, wobei allerdings noch ein kleiner, aber entscheidender Trick zur Anwendung kommt:

Die beiden 11-Bit-Werte max und min spannen definitionsgemäß einen Bereich möglicher erlaubter Werte auf, in dem die anderen Werte zu liegen kommen müssen.
Im Extrembeispiel ist max = 2047 und min = 0, dann müssen die anderen Werte alle zwischen 0 und 2047 liegen, zu deren Definition ebenfalls 11 Bit benötigt werden. In einem anderen Beispiel könnte max = 127 und min = 0 sein, dann wären zur Beschreibung aller möglichen dazwischenliegenden Werte lediglich 7 Bit notwendig.
Der Algorithmus bestimmt nun die Differenz zwischen max und min und ermittelt daraus, wie viele Bits zur Abdeckung dieses Wertebereichs oder Fensters benötigt werden. Die 14 extrahierten 7-Bit-Werte werden nun proportional zur Fenstergröße aufgeblasen, so daß sie innerhalb des jeweiligen 16-Werte-Blocks in gleichmäßigen Abständen diesen Bereich abdecken, auch wenn das "Aufblasen" natürlich dazu führt, daß die Schrittweite größer wird.
Für das zweite Beispiel oben mit dem gültigen Wertebereich von 0..127 würde das z.B. bedeuten, daß die 7 Bits des extrahierten Rohdatenwertes bereits ausreichen, um den 7-Bit-Bereich 0..127 abzudecken (und zwar lückenlos), eine Expansion ist also nicht mehr notwendig. Für das erste Beispiel mit dem Wertebereich 0..2047 muß der 7-Bit-Wert jedoch auf 11 Bit aufgeblasen werden, damit die 128 Werte des 7-Bit-Rohdatenwerts gleichmäßig innerhalb von 0..2047 zu liegen kommen. Pro "aufzublasendes" Bit erfolgt deshalb eine Multiplikation mit 2, hier also für 11-7 = 4 Bit eine Multiplikation mit 2*2*2*2 = 16. Der ursprüngliche Wert 0 bleibt dabei 0, ein ursprünglicher Wert von 1 ergäbe 16, aus 2 wird 32 usw. bis der höchstmögliche Wert 127 den Wert 2032 ergäbe. Die Abstände zwischen den beschreibbaren Werten sind in diesem Fall also 16, Zwischenwerte sind nicht darstellbar.
Hier bedient man sich eines weiteren Tricks, indem man nämlich das Fenster der Werte, das der jeweilige Wertebereich aufspannt, innerhalb des insgesamt darstellbaren Bereichs verschiebt, wobei die zuvor definierte Variable min gerade die untere Fenstergrenze definiert. Dafür muß man zu dem ggfs. aufgeblasenen Wert, der maximal den Wert 2032 annehmen kann und damit in 11 Bits paßt, einfach nur den zuvor definierten 11-Bit-Wert min addieren.
In unserem Beispiel für den Wertebereich 0..2047 war ja min = 0, und mit dem aufgeblasenen 7-Bit-Wert kamen wir maximal auf 2032. Wenn wir jetzt z.B. den Wert 2033 darstellen wollten, könnten wir das Fenster um eine Position auf 1 verschieben, so daß der Bereich 1..2033 abgedeckt wird. Hätte min den Wert 15, wären die Werte 15..2047 abgedeckt. Auf die gleiche Weise läßt sich auch jeder andere Wert zwischen den Zwischenwerten des aufgeblasenen Wertes erreichen. Da min aber nicht nur für einen Rohdatenwert gilt, sondern für alle 16 dieses Blocks, funktioniert dies nur solange gut, wie innerhalb dieses Blocks keine weitere Offset-Verschiebung notwendig wird.
Es ist auf diese Weise also nicht möglich, innerhalb des gleichen Blocks Werte wie 2032 und 2033 gleichzeitig zu beschreiben, wenn gleichzeitig auch Werte am unteren Ende der Skala wie 0, 1 etc. vorkommen. Dies ginge erst wieder im nächsten 16-Werte-Block, für den ja neue obere und untere Grenzen definiert werden können. Keine Einschränkung gibt es hingegen, wenn zwar Werte wie 2032 und 2033 beschrieben werden müssen, die anderen Werte dieses 16-Werte-Blocks aber ähnlich hoch liegen würden.
Hier könnte man das Fenster aus min und max z.B. von 1920 bis 2047 aufspannen. Die Differenz beträgt genau 127, läßt sich also mit den 7 Bits aus dem Rohdatenblock abdecken, ohne diese erst aufblasen zu müssen. In Gegensatz zu dem vorherigen Beispiel lassen sich nun alle Zwischenwerte darstellen, und dies auch unabhängig für jeden der 16 Rohdatenwerte aus diesem Block. Dafür ist eine Darstellung von Werten unterhalb von 1920 in diesem Beispiel nicht möglich.
Je nach Wahl der Fenstergröße und seiner Position innerhalb des Gesamtfensters 0..2027 kann man mit diesem Verfahren also ohne Verluste kleinste Werteschwankungen von einem Rohdatenwert zum nächsten wiedergeben, solange innerhalb des 16-Werte-Blocks keine Ausreißer nach oben oder unten dabei sind, oder es lassen sich über den gesamten Bereich verteilte Werte darstellen, dann aber nicht mehr mit voller Genauigkeit des 11-Bit-Wertes - die unteren Bits blieben dabei dann immer auf Null und es entstünde höheres Quantisierungsrauschen.
Das Verfahren stellt insgesamt fünf verschiedene Fenstergrößen zur Auswahl und davon abhängig können die Rohdatenwerte eine effektive Genauigkeit von 7 Bit bis 11 Bit haben. Die Kamera wird jeweils die Fenstergröße und Position wählen, die den kleinsten Datenverlust bedeutet; verlustfrei arbeitet der cRAW-Algorithmus im allgemeinen Fall also nicht (obwohl es Fälle gibt, in denen tatsächlich keine Daten verloren gehen).

Nachdem auf diese Weise die 16 11-Bit-Rohdatenwerte des jeweiligen Blocks ermittelt wurden, wird der Algorithmus dahingehend fortgesetzt, daß jeder dieser Werte durch eine Multiplikation mit 2 auf 12 Bit aufgebläht wird - das niederwertigste Bit bleibt dabei also immer Null. Dieser Wert fungiert als Index in ein großes Feld, das maximal 65536 16-Bit-Werte enthalten kann, die eine kameraspezifische Kurve definieren. Ob der Kurvenverlauf kameraspezifisch nach einer bestimmten Vorschrift von dcraw erzeugt wird oder ebenfalls in der Rohdatei abgelegt ist, habe ich noch nicht untersucht. In jeden Fall würde für die 11-Bit-Eingangswerte auch ein kleineres Feld ausreichen, als es mit curve[] in dcraw definiert ist und mit dem theoretisch auch 16-Bit-Rohdatenwerte abgebildet werden könnten.
Die resultierenden 16-Bit-Werte werden dann wieder durch 4 geteilt, so daß die zwei niederwertigsten Bits verloren gehen. Effektiv werden die 16 11-Bit-Werte also entlang des Kurvenverlaufs in 14-Bit-Rohdatenwerte übersetzt. Je nach Steilheit der Kurve ist somit selektiv eine effektive Genauigkeit von bis zu 14 Bit zu erreichen (bei flacher Kurve), an anderer Stelle kann die Auflösung jedoch stark reduziert sein (bei steiler Kurve). Die maximale Auflösung, die sich bei einem linearen Kurvenverlauf über den gesamten Bereich erzielen ließe, läge bei 11 Bit.

Die 16 resultierenden 14-Bit-Werte werden dann in der Rohbildmatrix gespeichert, allerdings innerhalb einer Zeile nicht linear hintereinander, sondern auf noch nicht näher untersuchte Weise verschachtelt (siehe "DEBUG"-Label - vielleicht hat jemand dafür eine gute Erklärung).

(Korrekturen und Ergänzungen sind ausdrücklich erwünscht.)

A cluster of 128 bits from line buffer holds data for 16 pixel data values
 
aaaa:aaaa aaab:bbbb bbbb:bbcc ccdd:ddee
eeee:efff ffff:gggg gggh:hhhh hhii:iiii
ijjj:jjjj kkkk:kkkl llll:llmm mmmm:mnnn
nnnn:oooo ooop:pppp ppqq:qqqq qrrr:rrrr
 
with
 
a (11 bits) = max (1 pixel data value)
b (11 bits) = min (1 pixel data value)
c (4 bits) = imax
d (4 bits) = imin
e, f, g, h, i, j, k, l, m, n, o, p, q, r (7 bits each) = 14 pixel data values
 

http://www.cybercom.net/~dcoffin/dcraw/dcraw.c

/*
 
[...]
 
   $Revision: 1.454 $
   $Date: 2012/12/23 19:25:36 $
*/
 
#define DCRAW_VERSION "9.17"
 
[...]
 
FILE *ifp;
 
short order; // signed 16-bit value
ushort raw_height, raw_width, height, width; // unsigned 16-bit values
ushort curve[0x10000]; // 16-bit index into 16-bit unsigned value
 
#define FORC(cnt) for (c=0; c < cnt; c++)
#define RAW(row, col) raw_image[(row)*raw_width+(col)]
 
[...]
 
void CLASS merror(void *ptr, const char *where)
{
   if (ptr)
      return;
 
   fprintf(stderr,_("%s: Out of memory in %s\n"), ifname, where);
 
   longjmp(failure, 1);
}
 
void CLASS derror()
{
   if (!data_error) {
      fprintf(stderr, "%s: ", ifname);
      if (feof(ifp))
         fprintf(stderr,_("Unexpected end of file\n"));
      else
         fprintf(stderr,_("Corrupt data near 0x%llx\n"), (INT64) ftello(ifp));
   }
 
   data_error++;
}
 
ushort CLASS sget2(uchar *s)
{
   if (order == 0x4949)         /* "II" means little-endian */
      return s[0] | s[1] << 8;
   else                         /* "MM" means big-endian    */
      return s[0] << 8 | s[1];
}
 
[...]
 
unsigned CLASS sget4(uchar *s)
{
   if (order == 0x4949)
      return s[0] | s[1] << 8 | s[2] << 16 | s[3] << 24;
   else
      return s[0] << 24 | s[1] << 16 | s[2] << 8 | s[3];
}
 
#define sget4(s) sget4((uchar *)s)
 
[...]
 
/*
   getbits(-1) initializes the buffer
   getbits(n) where 0 <= n <= 25 returns an n-bit integer
 */
 
unsigned CLASS getbithuff(int nbits, ushort *huff)
{
   static unsigned bitbuf=0;
   static int vbits=0, reset=0;
   unsigned c;
 
   if (nbits == -1)
      return bitbuf = vbits = reset = 0;
 
   if (nbits == 0 || vbits < 0)
      return 0;
 
   while (!reset && vbits < nbits && (c = fgetc(ifp)) != EOF &&
          !(reset = zero_after_ff && c == 0xFF && fgetc(ifp))) {
      bitbuf = (bitbuf << 8) + (uchar) c;
      vbits += 8;
   }
 
   c = bitbuf << (32-vbits) >> (32-nbits);
 
   if (huff) {
      vbits -= huff[c] >> 8;
      c = (uchar) huff[c];
   } else
      vbits -= nbits;
 
   if (vbits < 0)
      derror();
 
   return c;
}
 
#define getbits(n) getbithuff(n, 0)
#define gethuff(h) getbithuff(*h, h+1)
 
[...]
 
void CLASS sony_decrypt(unsigned *data, int len, int start, int key)
{
   static unsigned pad[128], p;
 
   if (start) {
 
      for (p=0; p < 4; p++)
         pad[p] = key = key * 48828125 + 1;
 
      pad[3] = pad[3] << 1 | (pad[0]^pad[2]) >> 31;
 
      for (p=4; p < 127; p++)
         pad[p] = (pad[p-4]^pad[p-2]) << 1 | (pad[p-3]^pad[p-1]) >> 31;
 
      for (p=0; p < 127; p++)
         pad[p] = htonl(pad[p]);
   }
 
   while (len--)
      *data++ ^= pad[p++ & 127] = pad[(p+1) & 127] ^ pad[(p+65) & 127];
}
 
void CLASS sony_load_raw() // for SRF files of DSC-F828 and DSC-V3
{
   uchar head[40];
   ushort *pixel;
   unsigned i, key, row, col;
 
   fseek(ifp, 200896, SEEK_SET);
   fseek(ifp, (unsigned) fgetc(ifp)*4 - 1, SEEK_CUR);
   order = 0x4D4D;
   key = get4();
   fseek(ifp, 164600, SEEK_SET);
   fread(head, 1, 40, ifp);
 
   sony_decrypt((unsigned int *) head, 10, 1, key);
 
   for (i=26; i-- > 22; )
      key = key << 8 | head[i];
 
   fseek(ifp, data_offset, SEEK_SET);
 
   for (row=0; row < raw_height; row++) {
 
      pixel = raw_image + row*raw_width;
 
      if (fread(pixel, 2, raw_width, ifp) < raw_width)
         derror();
 
      sony_decrypt((unsigned int *) pixel, raw_width/2, !row, key);
 
      for (col=0; col < raw_width; col++)
         if ((pixel[col] = ntohs(pixel[col])) >> 14)
            derror();
   }
 
   maximum = 0x3FF0;
}
 
void CLASS sony_arw_load_raw() // for ARW files of DSLR-A100/A200/A230/A290/A300/A330/A350/A380/A390
{
   ushort huff[32768];
   static const ushort tab[18] = {
      0xF11, 0xF10, 0xE0F, 0xD0E, 0xC0D, 0xB0C, 0xA0B, 0x90A, 0x809,
      0x708, 0x607, 0x506, 0x405, 0x304, 0x303, 0x300, 0x202, 0x201
   };
   int i, c, n, col, row, len, diff, sum=0;
 
   for (n=i=0; i < 18; i++)
      FORC(32768 >> (tab[i] >> 8)) huff[n++] = tab[i];
 
   getbits(-1);
 
   for (col = raw_width; col--;)
      for (row=0; row < raw_height+1; row+=2) {
 
         if (row == raw_height)
                row = 1;
 
         len = getbithuff(15, huff);
 
         diff = getbits(len);
 
         if ((diff & (1 << (len-1))) == 0)
            diff -= (1 << len) - 1;
 
         if ((sum += diff) >> 12)
            derror();
 
         if (row < height)
            RAW(row, col) = sum;
    }
}
 
void CLASS sony_arw2_load_raw() // for ARW files of DSLR-A700/A850/A900 in "cRAW" and DSLR-A450/A500/A550/A560/A580, SLT-A33/A35/A37/A55/A55V/A57/A58/A65/A65V/A77/A77V/A99/A99V, NEX-3/3C/C3/F3/3N/5/5C/5N/5R/5T/6/7/VG20/VG20E/VG30/VG30E/VG900/VG900E, ILCE-3000/5000/6000/7/7R, DSC-RX1/RX1R/RX10/RX100/RX100M2 and Hasselblad Lunar/Stellar/HV in "RAW"
{
   uchar *data, *dp;                       // pointers into compressed raw data line buffer
   ushort pix[16];                         // temporary buffer for cluster of 16 uncompressed raw values
                                           // (11 bits used, expandable up to 15 bits, theoretically up to 16 bits)
   int row, col, val, max, min, imax, imin, sh, bit, i; // these are signed 32-bit variables
   
   data = (uchar *) malloc(raw_width);     // allocate memory for one raw data line
   merror (data, "sony_arw2_load_raw()");  // bail out on allocation errors
 
   for (row=0; row < height; row++) {      // run through lines of compressed raw data
 
      fread(data, 1, raw_width, ifp);      // read compressed raw data into line buffer
 
      for (dp=data, col=0; col < raw_width-30; dp+=16) { // run through columns in line buffer,
                                           // process 16 bytes (128 bits) in one go
 
         // evaluate header of compressed cluster of pixel data by getting 32 bit value from buffer
 
         max = 0x7FF & (val = sget4(dp));  // max is bits 10..0 (11 bits for 0..2047)
         min = 0x7FF & val >> 11;          // min is bits 21..11 (11 bits for 0..2047)
         imax = 0x0F & val >> 22;          // imax is bits 25..22 (4 bits for 0..15)
         imin = 0x0F & val >> 26;          // imin is bits 29..26 (4 bits for 0..15)
 
         // bits 31 and 30 remain unused for header, but will be used for pixel data further below
 
         // max and min define highest and lowest margins in compressed cluster of 16 pixel data values.
         // 11 bits allow values of 0..2047 at most
 
         // imax and imin define which 2 data values in compressed cluster correspond with margin values
         // 4 bits are sufficient as an index into 16 pixel data values contained in cluster
 
         // determine bit width of window of values (max-min) in compressed pixel data cluster
 
         for (sh=0; ((sh < 4) && (0x80 << sh <= max-min)); sh++);
         // sh is 0 for window of 128, 1 for 256, 2 for 512, 3 for 1024, 4 for 2048 possible values
 
         // decompress 16 pixel data values from following 128-30 bit cluster in line buffer
 
         for (bit=30, i=0; i < 16; i++)    // start at bit 30 in 128 bit cluster
            if (i == imax)                 // is highest value in cluster?
               pix[i] = max;               // not stored inline, take from header as 11-bit
            else
               if (i == imin)              // is lowest value in cluster?
                  pix[i] = min;            // not stored inline, take from header as 11-bit
               else {                      // remaining 14 data values are stored inline as 7-bit values
                  pix[i] = ((sget2(dp+(bit >> 3)) // get sliding window of 16 bits from line buffer
                             >> (bit & 7)  // zero-align currently relevant 7 bits
                            & 0x7F)        // strip off other bits, lowest 7 bits make up value now
                           << sh)          // blow up in proportion to window size
                                           // (times 1 for 7, 2 for 8, 4 for 9, 8 for 10, 16 for 11 bits) 
                             + min;        // offset to low margin of window
 
                  // DEBUG 2013-01-07 MPL: Why is this necessary?
                  if (pix[i] > 0x7FF)      // 
                     pix[i] = 0x7FF;       // clip to highest possible value
 
                  bit += 7;                // move bit index to next 7 bits in the line
               }
 
         // convert 16 collected raw values to 12-bit/14-bit raw values and store in raw picture buffer
 
         for (i=0; i < 16; i++, col+=2)
            RAW(row, col) = curve[pix[i] << 1] >> 2;
                                           // blow up 11-bit raw value to 12-bit
                                           // (works with raw values up to 15 bits depending on curve definition),
                                           // apply camera curve (16 bits),
                                           // reduce to 14-bit (two LSBs get lost, if used at all in curve[]),
                                           // and store resulting raw value away as 2 bytes in raw picture buffer
                                           // (RAW macro addresses bytes in buffer, hence we must increment col by 2)
 
         // DEBUG 2013-01-07 MPL: What is this good for?
         col -= (col & 1) ? 1:31;          // substract 1 if column odd, 31 if even
 
      }
   }
   free(data); // free previously allocated memory
}
 
[...]
 

Viele Grüße,

Matthias

PS.
http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

Sehr gute Zusammenfassung! Kleine Ergänzung: Die jeweils in einen Block zusammengefassten Pixel sind stets aus der gleichen Farbkomponente - d.h. Ungenauigkeiten treten genau dann auf wenn es in einer Farbkomponente über 16 Spalten hinweg starke Unterschiede gibt. Das ist auch in Hinblick auf den AA-Filter und die Möglichkeiten des Sensors begrenzt: Denn theoretisch kann natürlich jeder Pixel des gesamten Bildes am Ende einem konkreten Wert der 14 Bit Bandbreite entsprechen, praktisch ist jedoch die lokale Auflösung begrenzt. Es gibt eine physisch bedingte Korrelation der Nachbarpixel, die hier dazu führen, dass es tatsächlich eher unwahrscheinlich zu Verlusten kommt.

Auch von meiner Seite noch ein paar Anmerkungen:

Da wir wissen, daß dcraw die Rohdateien der SLT-A99 problemlos verarbeiten kann und auch, daß dabei der oben beschriebene Dekompressionsalgorithmus zur Anwendung kommt, können wir schon mal folgende Feststellungen machen:

- Das RAW-Format der SLT-A99 (und anderer jüngerer Kameras wie der SLT-A33, SLT-A55, SLT-A57, SLT-A65 und diverser NEX-Gehäuse) ist identisch mit dem cRAW-Verfahren der DSLR-A700, DSLR-A850 und DSLR-A900. An der Datenrepräsentation des cRAW-Verfahrens mit 128-Bit-Blöcken für jeweils 16 Rohdaten hat sich nichts geändert, denn sonst würde der Dekompressionsalgorithmus grob falsche Ergebnisse liefern. Die 128 Bits werden (auf den ersten Blick) vollständig ausgenutzt (2 * 11 Bit + 2 * 4 Bit + 14 * 7 Bit), es kann also auch nicht sein, daß Sony in irgendwelche zuvor ungenutzten Bits dieses Blocks zusätzliche Informationen gepackt hat, die optional ausgewertet werden können. (Tatsächlich ist es so, daß sich mit etwas Nachdenken sehr wohl noch mehr Informationen verlustfrei in diese 128 Bit packen lassen, aber dies würde verschiedene Detailänderungen am Algorithmus erfordern - aber das ist mehr als Idee für Sony zu sehen, denn vorhandene Dateien lassen sich ja offenbar problemlos mit dem vorliegenden Algorithmus verarbeiten, was nicht möglich wäre, wenn solcherart Verfeinerungen bereits in den SLT-A99-Rohdateien verwirklicht wären. Vielleicht gehe ich darauf in einem späteren Beitrag noch etwas näher ein.)

- cRAW ist kein verlustloses Kompressionsverfahren, wie verschiedentlich im Netz (auch hier im Forum) geschrieben wurde. Tatsächlich ist es ein fünfstufig adaptives Verfahren, das hohe Präzision in Bereichen erlaubt, in denen diese "psychooptisch" gefordert ist, und dafür in anderen, weniger kritischen Bereichen ungenauer abbildet, um Bits zu sparen.

- Wenn wir die Anwendung der kameraspezifischen Kurve im Dekompressor mal außen vor lassen, da diese bereits Teil der Rohdatenverarbeitung im Rohdatenkonverter ist, und auf der "Gegenseite", der Kamera mit ihrer cRAW-Kompressionsroutine nicht vorkommt, dann können wir sagen, daß cRAW eine maximale Genauigkeit von bis zu 11 signifikanten Bitstellen erreicht (wo nötig) und dafür in anderen Bereichen die Genauigkeit auf 7 signifikante Stellen reduziert wird. (Zum Vergleich: In 128 Bits entsprechend 16 Bytes könnte man 16 Rohdaten auch mit einer durchgehenden Genauigkeit von 8 Bit speichern.)
Gegenüber einer Speicherung aller Rohdaten als unkomprimierte 12-Bit-Werte nach dem alten "echten" RAW-Verfahren geht hier natürlich potentiell einiges an Information verloren, die Frage ist nur, ob die zur Verfügung stehende Bitbreite innerhalb der Kamera überhaupt ausgenutzt wurde. Wenn die Daten dort sowieso nicht mit 12 Bit Genauigkeit vorliegen, braucht man sie auch nicht in 12 Bit zu speichern; dann reichen auch 11 Bit oder weniger, ohne daß effektiv Information verlorengeht.
Wenn die SLT-A99 jetzt aber mit 14 Bit beworben wird, stellt sich schon die Frage, ob die Speicherung in 11-Bit-Werten (und dies ja auch nur im bestmöglichen Fall) noch adequat ist. Meine persönliche Meinung dazu:
"Nein, der Sinn und Zweck des Rohdatenformats ist es gerade, möglichst unmittelbaren Zugriff auf die vom Sensor gelesenen Werte zu bekommen, auf daß mehr oder weniger aufwendige Bearbeitungsverfahren im Rohdatenkonverter bzw. in der Bildbearbeitung zur Anwendung kommen können. Potentielle 12-Bit- und erst recht noch 14-Bit-Daten verlustbehaftet durch ein 7-bis-11-Bit-Nadelöhr zu pressen, ist dabei nicht sinnvoll - jedenfalls nicht, wenn man es nicht abschalten kann. Ob Effekte sichtbar werden oder nicht, sollte der Beurteilung des Anwenders bzw. der Anwendung überlassen bleiben, statt daß Sony hier schon eine Entscheidung vorwegnimmt. So wie jetzt muß zwangsläufig die berechtigte Frage aufkommen, ob die interne Verarbeitung in der Kamera überhaupt wie beworben 14 Bit breit organisiert ist. Dadurch, daß keine 14-Bit-Daten nach außen geliefert werden (auch keine 12-Bit-Daten), wird der Blick ins Innere verwehrt, es müssen also berechtigte Zweifel entstehen, ob die von Sony in diesem Punkt gemachten technischen Daten überhaupt den Tatsachen entsprechen - und selbst wenn, welchen Nutzen sie haben (außer für eine kamerainterne JPEG-Generierung und Bildeffekte), wenn man nicht die vollen Daten zu Gesicht bekommt."

- Die bei dem vorliegenden Algorithmus einzige Möglichkeit, aus den vorhandenen cRAW-Dateien unterschiedlich breite Rohdaten im Konverter zu generieren, besteht in einer Anpassung der kameraspezifischen Kurve, über die die dekomprimierten 11-Bit-Daten in einen 14-Bit-Raum abgebildet werden. Egal wie man's auch dreht und wendet, selbst wenn eine angepaßte Kurve hier 14-Bit-Daten am Ausgang liefert, es bleiben davon nur maximal 11 signifikante Stellen übrig, sprich, es können auch nur maximal 2048 verschiedene Werte angenommen werden, nicht 4096 oder 16384, wie dies bei echten 12-Bit- bzw. 14-Bit-Daten der Fall wäre.

- Da es softwareseitig trivial einfach ist, neben einer solchen komprimierten Speicherung auch noch ein echtes 14-Bit-Rohdatenformat ähnlich dem alten 12-Bit-Rohdatenformat anzubieten, verstehe ich nicht, warum Sony diese Option nicht mehr im Menü anbietet.
Auch ließen sich beide Verfahren mit wenig zusätzlichem Rechenaufwand so kombinieren, daß abhängig vom Eingangsdatenstrom das adaptive Kompressionsverfahren immer dann zum Einsatz kommt, wo es nach der späteren Dekompression deterministisch vorhersagbar bitidentische Ergebnisse liefert, und dort, wo dies nicht der Fall ist (was die Kamera bereits zum Zeitpunkt der Kompression erkennen muß und kann), die Werte unkomprimiert gespeichert werden. Auf diese Weise wären Kompressionsraten möglich, die in den meisten Fällen nicht allzu weit hinter denen des verlustbehafteten cRAW-Verfahrens lägen, daß es sich nun aber um eine tatsächlich verlustlose Kompression handeln würde, gegen die man keine Einwände haben kann, da sie nicht die Wahl zwischen zwei Übeln läßt, sondern das Angenehme mit dem Nützlichen verbindet.
Für mich erwächst hieraus klar ein weiterer Wunsch für unseren Firmware-Verbesserungsideen-Thread:

http://www.mi-fo.de/forum/viewtopic.php?t=32727

Viele Grüße,

Matthias

Vielen Dank für Deine Detektivarbeit und die interessanten Ergebnisse!

Ein paar Anmerkungen insbesondere zu den bewertenden Bereichen:

ZITAT(matthiaspaul @ 2013-01-08, 15:57) - Das RAW-Format der SLT-A99 (und anderer jüngerer Kameras wie der SLT-A33, SLT-A55, SLT-A57, SLT-A65 und diverser NEX-Gehäuse) ist identisch mit dem cRAW-Verfahren der DSLR-A700, DSLR-A850 und DSLR-A900. An der Datenrepräsentation des cRAW-Verfahrens mit 128-Bit-Blöcken für jeweils 16 Rohdaten hat sich nichts geändert, denn sonst würde der Dekompressionsalgorithmus grob falsche Ergebnisse liefern.[/quote]

Das ist korrekt und wurde u. A. von mir diverse Male so kommentiert.

ZITAT(matthiaspaul @ 2013-01-08, 15:57) - cRAW ist kein verlustloses Kompressionsverfahren, wie verschiedentlich im Netz (auch hier im Forum) geschrieben wurde. Tatsächlich ist es ein fünfstufig adaptives Verfahren, das hohe Präzision in Bereichen erlaubt, in denen diese "psychooptisch" gefordert ist, und dafür in anderen, weniger kritischen Bereichen ungenauer abbildet, um Bits zu sparen.[/quote]

Mir behagt die Bezeichnung "kein verlustloses Kompressionsverfahren" bzw. einfacher "Verlustbehaftetes Kompressionsverfahren" im Zusammenhang mit cRAW nicht. Nicht das es sicher falsch wäre - es ist nur einfach zuviel gefolgert, denn leider ist dcraw.c nur die eine Seite der Gleichung und wir können das Bild nicht in der von Dir genannten Art vervollständigen. Warum ist das so? Du vermutest als Begründung für die Adaption des Speicherformats "psychooptische" Effekte - also ähnlich wie bei JPEG oder wie mit MP3 bei Audio. Ich halte es aber für plausibler, dass die Grundlage der Adaption nicht der Mensch (psycho...) sondern die Kamera ist. Die ADC-Wandler des Sensors und die Verarbeitungspipeline müssen eine Bandbreite zur Verarbeitung festlegen. Dies kann sinnvollerweise nur das Maximum dessen sein was Sinn macht - also bislang 12 Bit und bei der A99 14 Bit. Das bedeutet NICHT, dass die Kamera tatsächlich 14 Bit auflöst! Es ist sogar eher unwahrscheinlich. Hinzu kommt, dass die Sensoren selbst das Signal linear aufzeichnen - was für das Tonwertkomprimierte Endresultat irrelevant ist: Lichter und Schatten werden durch die Gammakurve später komprimiert. Die unkomprimierten linearen Werte sind höchstens algorithmisch interessant - nicht jedoch für die eigentliche Bildnutzung. Die Hersteller beeinflussen hier durch kameraspezifische Kurven, wie die linear aufgezeichneten Werte verwendet werden. Je nachdem ob Lichter oder Schatten optimiert werden sollen, können diese Kurven die Tonwert-Kompression unterschiedlich auslegen. Diese Kurven sind tatsächlich psychooptisch bestimmt und entscheidend dafür ob der Output einer Kamera gefällig erscheint oder eben nicht. Wir müssen schlicht akzeptieren, dass die Kamerahersteller für ihre Produkte selbst entscheiden, wie die tatsächlichen Rohdaten zu einem "gefälligen" Look geformt werden. Hier liegt auch schlicht das Kapital und es ist verständlich, dass die Hersteller das nicht einfach aus der Hand geben.


ZITAT(matthiaspaul @ 2013-01-08, 15:57) - Wenn wir die Anwendung der kameraspezifischen Kurve im Dekompressor mal außen vor lassen, da diese bereits Teil der Rohdatenverarbeitung im Rohdatenkonverter ist, und auf der "Gegenseite", der Kamera mit ihrer cRAW-Kompressionsroutine nicht vorkommt, dann können wir sagen, daß cRAW eine maximale Genauigkeit von bis zu 11 signifikanten Stellen erreicht (wo nötig) und dafür in anderen Bereichen die Genauigkeit auf 7 signifikante Stellen reduziert wird. (Zum Vergleich: In 128 Bits entsprechend 16 Bytes könnte man 16 Rohdaten auch mit einer durchgehenden Genauigkeit von 8 Bit speichern.)[/quote]

Wir können mit hoher Wahrscheinlichkeit davon ausgehen, dass bereits vor der Speicherung der RAW-Daten eine tatsächlich in der Kamera auf die linearen Werte angewendete kameraspezifische Kurve angewandt wird. Die (geringe) Kompression dieser Kurve kombiniert mit einer Rauschfilterung liefert im cRAW am Ende 11 "saubere" Bits. Mit der bisherigen maximalen Tonwertauflösung von 12 Bit hätte man ein Bit verloren - das würde schnell im Rauschen untergehen. Die 14 Bit der A99 sind da schon etwas anders: in der Theorie werden durch Rauschfilterung und Kurven 3 Bit weggepresst. Ich vermute, dass die niedrigen Tonwerte der A99 deutlich weniger verrauscht sind als jene der 12 Bit A900 und das dies eine Folge der 14 Bit Verarbeitung ist. Natürlich kann man immer Argumentieren, dass es doch viel "freiheitlicher" und "offen" wäre, wenn der Hersteller die rohen Werte herausgibt und das jeder seine individuelle 14 Bit -> 11 Bit Verarbeitung machen kann - aber ich denke das dazu wirklich extensives Detailwissen über die Sensoren und andere Bereiche notwendig sind und das der Nutzen das möglicherweise wenig ausgleicht.

ZITAT(matthiaspaul @ 2013-01-08, 15:57) Gegenüber einer Speicherung aller Rohdaten als unkomprimierte 12-Bit-Werte nach dem alten "echten" RAW-Verfahren geht hier natürlich potentiell einiges an Information verloren, die Frage ist nur, ob die zur Verfügung stehende Bitbreite innerhalb der Kamera überhaupt ausgenutzt wurde. Wenn die Daten dort sowieso nicht mit 12 Bit Genauigkeit vorliegen, braucht man sie auch nicht in 12 Bit zu speichern; dann reichen auch 11 Bit oder weniger, ohne daß effektiv Information verlorengeht.[/quote]

Absolut! Man sollte auch bedenken, dass die 12 bzw. 14 Bit eine globale Grenze sind - das ist die Maximalgröße der Töpfchen. Das Problem ist schlicht, dass das eingießen in diese Töpchen so ungenau ist, dass man NIEMALS von einem Töpchen zum nächsten die komplette Füllhöhe ausnutzen kann. Bereiche mit vielen vollen Töpchen enthalten praktisch nie gänzlich leere Töpchen in der Nachbarschaft. Dadurch ergibt sich eine Adaptionsmöglichkeit von der ich ausgehe, das diese intelligent durch das cRAW-Verfahren ausgenutzt wird.

ZITAT(matthiaspaul @ 2013-01-08, 15:57) Wenn die SLT-A99 jetzt aber mit 14 Bit beworben wird, stellt sich schon die Frage, ob die Speicherung in 11-Bit-Werten (und dies ja auch nur im bestmöglichen Fall) noch adequat ist. Meine persönliche Meinung dazu:
"Nein, der Sinn und Zweck des Rohdatenformats ist es gerade, möglichst unmittelbaren Zugriff auf die vom Sensor gelesenen Werte zu bekommen, auf daß mehr oder weniger aufwendige Bearbeitungsverfahren im Rohdatenkonverter bzw. in der Bildbearbeitung zur Anwendung kommen können. Potentielle 12-Bit- und erst recht noch 14-Bit-Daten verlustbehaftet durch ein 7-bis-11-Bit-Nadelöhr zu pressen, ist dabei nicht sinnvoll - jedenfalls nicht, wenn man es nicht abschalten kann. Ob Effekte sichtbar werden oder nicht, sollte der Beurteilung des Anwenders bzw. der Anwendung überlassen bleiben, statt daß Sony hier schon eine Entscheidung vorwegnimmt. So wie jetzt muß zwangsläufig die berechtigte Frage aufkommen, ob die interne Verarbeitung in der Kamera überhaupt wie beworben 14 Bit breit organisiert ist. Dadurch, daß keine 14-Bit-Daten nach außen geliefert werden (auch keine 12-Bit-Daten), wird der Blick ins Innere verwehrt, es müssen also berechtigte Zweifel entstehen, ob die von Sony in diesem Punkt gemachten technischen Daten überhaupt den Tatsachen entsprechen - und selbst wenn, welchen Nutzen sie haben (außer für eine kamerainterne JPEG-Generierung und Bildeffekte), wenn man nicht die vollen Daten zu Gesicht bekommt."[/quote]

Das ist eine wohlfeile Meinung. Ich erkenne darin auch die Zeichen des Bastlers und den neugierigen Geist, der gerne unter die Motorhaube oder in das Gehäuse schaut. Ich möchte dem eine konträre Meinung gegenüberstellen:
"Ja, die 11 Bit Speicherung kann durchaus noch adequat sein, wenn sie im Großen und Ganzen ausreicht um die Fähigkeiten der Hardware wiederzugeben. Nur weil die maximale Bitzahl auf 14 Bit erhöht wurde heißt das noch lange nicht, dass die zusätzlichen zwei Bits stets voll genutzt werden. Wenn ein verbesserter Sensor und Fortschritte in der Halbleitertechnik nun ermöglichen, dass man 14 Bit Werte erfasst und dass die Verarbeitung zum Alpha-RAW-Format rauschärmere Schatten ohne Detailverlust ermöglicht, dann liegt ein realer Nutzen für die 14-Bit-Verarbeitung vor. Demgegenüber steht, dass ein inkompatibles ARW-Format die Auswahl an RAW-Konvertern kurz- oder mittelfristig ziemlich deutlich verringern würde.



ZITAT(matthiaspaul @ 2013-01-08, 15:57) - Die bei dem vorliegenden Algorithmus einzige Möglichkeit, aus den vorhandenen cRAW-Dateien unterschiedlich breite Rohdaten im Konverter zu generieren, besteht in einer Anpassung der kameraspezifischen Kurve, über die die dekomprimierten 11-Bit-Daten in einen 14-Bit-Raum abgebildet werden. Egal wie man's auch dreht und wendet, selbst wenn eine angepaßte Kurve hier 14-Bit-Daten am Ausgang liefert, es bleiben davon nur maximal 11 signifikante Stellen übrig, sprich, es können auch nur maximal 2048 verschiedene Werte angenommen werden, nicht 4096 oder 16384, wie dies bei echten 12-Bit- bzw. 14-Bit-Daten der Fall wäre.[/quote]

Vermutlich musst Du nur die Bereiche auf 14 Bit strecken und ein bisschen weißes Rauschen in den untersten 2 Bits einbringen und hast dann ein Ergebnis das der "Realität" nahe kommt. ;-).

ZITAT(matthiaspaul @ 2013-01-08, 15:57) - Da es softwareseitig trivial einfach ist, neben einer solchen komprimierten Speicherung auch noch ein echtes 14-Bit-Rohdatenformat ähnlich dem alten 12-Bit-Rohdatenformat anzubieten, verstehe ich nicht, warum Sony diese Option nicht mehr im Menü anbietet.[/quote]

Ich sehe auch kein softwareseitiges Problem. Allerdings war cRAW auf jeden Fall bislang kein Hindernis - niemand hat je zeigen können, dass damit überhaupt irgendein Unterschied rauskommt. Es hängt eben doch von der Verteilung des Eingabekanals ab ob sich cRAW überhaupt "Verlustbehaftet" ausdrücken kann.

ZITAT(matthiaspaul @ 2013-01-08, 15:57) Auch ließen sich beide Verfahren mit wenig zusätzlichem Rechenaufwand so kombinieren, daß abhängig vom Eingangsdatenstrom das adaptive Kompressionsverfahren immer dann zum Einsatz kommt, wo es nach der späteren Dekompression deterministisch vorhersagbar bitidentische Ergebnisse liefert, und dort, wo dies nicht der Fall ist (was die Kamera bereits zum Zeitpunkt der Kompression erkennen muß und kann), die Werte unkomprimiert gespeichert werden. Auf diese Weise wären Kompressionsraten möglich, die in den meisten Fällen nicht allzu weit hinter denen des verlustbehafteten cRAW-Verfahrens lägen, daß es sich nun aber um eine tatsächlich verlustlose Kompression handeln würde, gegen die man keine Einwände haben kann, da sie nicht die Wahl zwischen zwei Übeln läßt, sondern das Angenehme mit dem Nützlichen verbindet.
Für mich erwächst hieraus klar ein weiterer Wunsch für unseren Firmware-Verbesserungsideen-Thread:[/quote]

Dazu müsste die Kamera den kompletten RAW-Strom im zweifel zwei mal verarbeiten - das halte ich für durchaus verschwenderisch. "Bitidentische Ergebnisse" finde ich eine zu starke Vorgabe. Eine Kamera ist nie so exakt, dass man von einer solchen Vorgabe irgendeinen praktischen Nutzen ziehen könnte. Ansonsten: Wie bereits erwähnt - es fehlen noch Teile des Puzzles um überhaupt legitim aussagen zu können ob cRAW verlustbehaftet ist oder nicht. Sonys offizielle Aussage ist "nein".

[neon]

Mein Interesse am Sony-cRAW-Verfahren ist ja erst durch die aktuelle Diskussion 12-Bit vs. 14-Bit bei der SLT-A99 geweckt worden (ich habe bisher nur im "echten" 12-Bit-RAW-Modus der DSLR-A900 gearbeitet). Auf der Suche nach Erklärungen für einige Ungereimtheiten des in dcraw implementierten Dekompressionsalgorithmus, der ja selbst durch Reverse Engineering entstanden ist, und auch auf der Suche nach Antworten zu verschiedenen noch ungeklärten Fragen bezüglich der kameraseitigen Kompression habe ich zwar noch keine Antworten gefunden, aber einige andere lesenswerte Threads, die den cRAW-Algorithmus auch schon beleuchtet haben, z.T. auch schon vor langer Zeit. Die möchte ich Euch keinesfalls vorenthalten, deshalb folgt eine kleine Link-Sammlung:

http://www.sonyuserforum.de/forum/showthread.php?t=79615
http://www.sonyuserforum.de/forum/showthread.php?t=91346
http://wws.sonyuserforum.de/forum/showthread.php?t=96889
http://www.dyxum.com/dforum/sony-a900-craw...topic41098.html
http://www.dyxum.com/dforum/the-consolidat...topic22802.html
http://www.dyxum.com/dforum/topic22057.html
http://forums.dpreview.com/forums/thread/2...m-post-26125529
http://www.dyxum.com/dforum/a700-arw-findi...topic21214.html
http://www.mi-fo.de/forum/index.php?showto...st&p=213917

Daß in manchen dieser Diskussionen von 12 Bit und 8 Bit die Rede ist, statt von 11 Bit und 7 Bit, wie von mir oben beschrieben, liegt einfach nur daran, daß manche sich auf die Bitbreite des Eingangswerts für die kameraspezifische Kurve (curve[]) beziehen, die tatsächlich 12-bittig ist, bei dem aber das niederwertigste Bit immer 0 bleibt, da der Wert aus dem 11-Bit-Wert einfach durch Multiplikation mit 2 entsteht.

#define RAW(row, col) raw_image[(row)*raw_width+(col)]
 
[...]
 
                  for (i=0; i < 16; i++, col+=2)
                     RAW(row, col) = curve[pix[i] << 1] >> 2;
 

Das mag in Bezug auf den gemeinsamen Code für die Kamerakurve implementierungstechnisch einfacher sein, aber es ließe sich mit einer angepaßten (kleineren) Kurve auch realisieren, ohne den Wert künstlich aufzublähen.

Gerade an dieser Stelle gab es im Laufe der Versionsgeschichte von dcraw eine Änderung, denn früher wurde der resultierende Wert nur durch 2 statt wie heute durch 4 geteilt.

#define FC(row, col) (filters >> ((((row) << 1 & 14) + ((col) & 1)) << 1) & 3)
#define BAYER(row, col) image[((row) >> shrink)*iwidth + ((col) >> shrink)][FC(row, col)]
 
[...]
 
                  for (i=0; i < 16; i++, col+=2)
                     BAYER(row, col) = curve[pix[i] << 1] >> 1;
 

Wann diese Änderung stattfand, weiß ich nicht, sie scheint aber mehr mit der Implementierung in dcraw zu tun zu haben, als mit dem Dekompressionsalgorithmus selbst.

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2013-01-07, 23:50) http://www.cybercom.net/~dcoffin/dcraw/dcraw.c

.
.
.
         // DEBUG 2013-01-07 MPL: What is this good for?
         col -= (col & 1) ? 1:31;          // substract 1 if column odd, 31 if even
 
.
.
.
 

[/quote]
Hallo Matthias,

nur kurz zu deinem zweiten DEBUG.

Das liegt am Bayer Pattern, z.B.:

GBGB...
RGRG...

Es werden zunächst die ersten 16 Grünwerte eingetragen, dann muss um 31 zurückgesprungen werden, um die Blauwerte einzutragen. Danach (ungerade Spalte) geht's mit den nächsten Grünwerten weiter.

BG Hans

ZITAT(Neonsquare @ 2013-01-09, 12:33) ZITAT(matthiaspaul @ 2013-01-08, 15:57) - cRAW ist kein verlustloses Kompressionsverfahren, wie verschiedentlich im Netz (auch hier im Forum, meiner Erinnerung nach auch von mir) geschrieben wurde. Tatsächlich ist es ein fünfstufig adaptives Verfahren, das hohe Präzision in Bereichen erlaubt, in denen diese "psychooptisch" gefordert ist, und dafür in anderen, weniger kritischen Bereichen ungenauer abbildet, um Bits zu sparen.[/quote]

Mir behagt die Bezeichnung "kein verlustloses Kompressionsverfahren" bzw. einfacher "Verlustbehaftetes Kompressionsverfahren" im Zusammenhang mit cRAW nicht. Nicht das es sicher falsch wäre - es ist nur einfach zuviel gefolgert, denn leider ist dcraw.c nur die eine Seite der Gleichung und wir können das Bild nicht in der von Dir genannten Art vervollständigen. Warum ist das so? Du vermutest als Begründung für die Adaption des Speicherformats "psychooptische" Effekte - also ähnlich wie bei JPEG oder wie mit MP3 bei Audio. Ich halte es aber für plausibler, dass die Grundlage der Adaption nicht der Mensch (psycho...) sondern die Kamera ist.
[/quote]
Da sprichst Du direkt mehrere sehr interessante Punkte an:

Zunächst mal, vermutlich hast Du Recht, daß der Algorithmus hier weniger oder gar nicht auf unsere Sehgewohnheiten Rücksicht nimmt, als mit Vorwissen um physikalisch-technische Gegebenheiten optischer oder elektronischer Natur die Genauigkeit der abgelegten Daten an die tatsächlich vor Ort von der Hardware erzielbare Genauigkeit anpaßt. Auf diese Weise kann dieser dafür optimierte Kompressionsalgorithmus mit relativ wenig Rechenaufwand und lokalem Speicherbedarf einen ziemlich hohen Kompressionsfaktor erreichen, was ja für die Implementierung im Signalprozessor der Kamera wichtig ist, damit die Daten mit nur minimalen Verzögerungen verarbeitet werden können.
Ohne, daß ich das jetzt genauer untersucht hätte, verlustlose Kompressionsalgorithmen nach Lempel-Ziv-Welch etc., ggfs. noch speziell für die vorliegende Aufgabe adaptiert, dürften zwar noch höhere Kompressionsraten schaffen, aber auch mehr Ressourcen verbrauchen und lassen sich vermutlich auch nicht so gut "streamen", aber das ist jetzt erstmal nur eine Vermutung.

Der zweite Punkt, den Du ansprichst, betrifft die Tatsache, daß wir ja nur die Dekompressionsroutine in dcraw kennen, nicht die Kompressionsroutine in der Kamera, und die Implementierung in dcraw basiert letztlich nur auf Reverse Engineering auf der Grundlage vorhandener ARW-Dateien, nicht auf irgendeiner offiziellen Dokumentation des Datenformats oder des Kompressionsverfahrens durch Sony. Würde es sich um ein verlustfrei arbeitendes Verfahren handeln, wäre das nicht wichtig. Nach einer gewissen Zeit des Experimentierens könnte man praktisch sicher sein, das richtige Dekompressionsverfahren gefunden zu haben und bräuchte sich keine Sorgen mehr zu machen. Gerade weil es sich aber nicht um ein verlustfreies Verfahren handelt, ist die fehlende offizielle Dokumentation hier, wie ich finde, problematisch, denn der Dekompressionsalgorithmus liefert zwar ein Ergebnis, das auf den ersten Blick auch sehr vernünftig aussieht, aber da das Ergebnis nicht bitidentisch mit dem sein muß, was zuvor in der Kamera vorlag, können wir nicht sicher wissen, daß dies wirklich alles ist, was hinter dem Verfahren steckt.

Ich habe ja weiter oben schon durchblicken lassen, daß der Dekompressionsalgorithmus bei mir verschiedene Fragen aufwirft, weil er an einigen Stellen sozusagen etwas "unrund" läuft, und ich vermute, daß Dir ganz ähnliche Dinge aufgefallen sind.

Es gibt z.B. eine ganze Reihe von Fällen, die überhaupt nicht berücksichtigt werden. Es ist möglich, daß diese Fälle in real existierenden ARW-Dateien einfach nie vorkommen und deshalb nicht berücksichtigt werden müssen, aber es wäre auch denkbar, daß der Kompressionsalgorithmus der Kamera hier durchaus noch etwas komplexer ist, als es uns der vorliegende Dekompressionsalgorithmus Glauben macht - und dann gingen bei der Dekompression u.U. "versteckte" Informationen verloren, die eigentlich noch genutzt werden könnten, um die Qualität der Dekompression zu verbessern.
Einige dieser Fälle ließen sich softwareseitig detektieren, da sie bestimmte "Muster" im 128-Bit-Datenblock erzeugen, die eigentlich nie vorkommen dürften. Andere Fälle könnten als Metadaten in den Nutzdaten selbst "versteckt" sein, und man würde sie ohne Vorwissen, daß sie existieren, nicht detektieren können (ähnlich wie Wasserzeichen) und dementsprechend auch nicht nutzen können.
Das sind Gründe, warum ich mir an dieser Stelle ein verlustfreies Kompressionsverfahren wünschen würde, so daß sich außerhalb der Kamera bitidentische Daten rekonstruieren lassen und man nicht darauf angewiesen bleibt, Daten bestmöglich zu "interpretieren".

Ich werfe mal ein paar Fragen auf:

- Man könnte vereinfachend annehmen, daß der Algorithmus so "binär" arbeitet, daß die Fensterposition, passend zur Fenstergröße, immer so entlang der Wertigkeit im Zweiersystem positioniert wird, daß das Fenster nie über den 11-Bit-Raum hinausragt. Nur in den Fällen, in denen das nicht so ist, können bei der min-Addition 12-Bit-Daten entstehen, die der Algorithmus dann sofort wieder auf 11 Bit zurechtstutzt:

                  if (pix[i] > 0x7FF)
                     pix[i] = 0x7FF;
 

Hier wäre zu klären, ob dieser Fall in der Praxis überhaupt vorkommt (da Du und Hans den Code in der Entwicklungsumgebung habt, könnt ihr ja mal im Debugger eine Trap auf diese Bedingung setzen). Falls nein, kann man sich die Abfrage sparen und bekommt einen Performance-Gewinn. Falls ja, stellt sich einerseits die Frage, ob es wirklich notwendig ist, die Daten zu clippen (etwa, weil sie dann auch invalide sind), denn eigentlich müßten wir froh über jedes zusätzliche Bit sein, und schließlich müßte dieser Fall auch durch curve[], dessen Eingangsindex ja 16 Bit breit ist, sauber abgefangen werden können (vorausgesetzt, die Kurve ist vollständig definiert). Außerdem ist anzunehmen, daß diese Daten, wenn sie denn tatsächlich im Nutzdatenstrom vorkommen, kein reines Artefakt sind, sondern auch Information enthalten. Warum sollten wir die durch Clippen verschenken? Die Beantwortung dieser Frage könnte auch Rückschlüsse auf die konkrete Implementierung in der Kamera in Bezug auf eine mögliche Rauschformung zulassen, die wir dekompressionsseitig zusätzlich ausnützen könnten, wenn wir darum wüßten.

- Warum ist der Algorithmus auf einen maximalen Shift-Wert (sh) von 4 beschränkt?

         max = 0x7FF & (val = sget4(dp));
         min = 0x7FF & val >> 11;
[...]
         for (sh=0; ((sh < 4) && (0x80 << sh <= max-min)); sh++);
 

sh kann hier die Werte 0 bis 4 annehmen, die Fensterhöhen von 128, 256, 512, 1024 und 2048 Werten bzw. einer Multiplikation der 7-Bit-Werte mit 1, 2, 4, 8 oder 16 entsprechen. Da sh aber ausschließlich durch max und min bestimmt wird, bei denen es sich um 11-Bit-Werte (0..2047) handelt, stellt 2047-0 = 2047 den größten Wert auf der rechten Seite der Bedingung dar. Mit sh = 4 stünde auf der linken Seite 128 << 4 = 2048, also "2048 <= 2047", was zum Abbruch der Schleife führen würde. Demnach müßte der folgende kürzere (und möglicherweise sogar etwas schnellere) Code exakt das Gleiche bewirken und sich nebenbei "automatisch" an noch größere Fensterhöhen anpassen, sollte(n) min (und max) auf mehr als 11 Bit erweitert werden:

         for (sh=0; 0x80 << sh <= max-min; sh++);
 

Da stellt sich dann direkt die Frage, ob es einen Grund geben könnte, den Algorithmus an dieser Stelle künstlich auf 11 Bit zu begrenzen, wenngleich er eigentlich auch mit mehr Bits arbeiten würde.

- Die nächste Überlegung zielt darauf ab, ob der Algorithmus korrekt reagiert, wenn die von max und min aufgespannte Fensterhöhe kleiner als 128 Werte (entsprechend der bereitgestellten 7-Bit-Daten) werden würde. Meiner Analyse nach würde der Algorithmus mit dieser Bedingung robust weiterarbeiten, d.h. er würde weiterhin eine Fensterhöhe von 128 Werten annehmen (warum sollte man weniger nehmen, wenn schon mal 7-Bit-Daten geliefert werden? - außer die LSBs des 7-Bit-Wertes müßten dann anders interpretiert werden), d.h. es würde zunächst einmal überhaupt nicht auffallen, wenn diese Bedingung in real existierenden Rohdaten tatsächlich vorliegt - der Dekompressionsalgorithmus würde vernünftige Daten liefern.

Hat das schon mal jemand untersucht, ob es Dateien, z.B. angebliche 14-Bit-Dateien von der SLT-A99 gibt, in denen diese Bedingung vielleicht erfüllt ist?

Ich frage dies, weil dies eine Möglichkeit für Sony wäre, zusätzliche Bits für max und min unterzubringen, die ein Algorithmus, der davon weiß, nutzen kann, die aber ein Algorithmus wie der obige einfach überlesen würde. Wie das?

Beispiel:

Die Differenz max-min wird bisher implizit als mindestens 128 angenommen (eigentlich: größer 64), nennen wir dies mal Fall 1. Wäre sie nun kleiner-gleich 64, könnte man diese Bedingung als Fall 2 annehmen, kleiner-gleich 32 wäre Fall 3, kleiner-gleich 16 Fall 4, kleiner-gleich 8 Fall 5, kleiner-gleich 4 Fall 6, kleiner-gleich 2 Fall 7, kleiner-gleich 1 Fall 8, gleich 0 Fall 9. In 8 Fällen kann man 3 unabhängige Bits kodieren.
Ein weiteres Bit könnte man in der Bedingung unterbringen, ob die Differenz aus max-min positiv oder negativ ist. Würden die beiden Werte im Header vertauscht, würde der bisherige Algorithmus nicht mehr arbeiten, ließe sich aber leicht anpassen, indem er die Werte für die weitere Auswertung einfach zurücktauscht, sich aber merkt, daß sie vertauscht waren und dies als viertes unabhängiges Bit betrachten.

Auf diese Weise könnten wir also ohne Änderung des Verfahrens je ein zusätzliches LSB für min und max herbeizaubern (also 12 Bit statt 11 Bit), die ein herkömmlicher Algorithmus einfach überlesen würde. (Dies allerdings nur für Fensterhöhen von maximal 64.)

Mit einer minimalen Änderung des Verfahrens (max-min Differenz positiv/negativ) wären sogar zwei Bits für min und max zu holen (also 13 Bit statt 11 Bit).

Und nach einer weiteren kleinen Änderung könnte man für Fensterhöhen von maximal 64 Werten die niederwertigsten Bits des 7-Bit-Wertes nicht, wie gehabt, als Teil des Faktors interpretieren, sondern könnte jedem der 14 Werte ein zusätzliches unabhängiges LSB spendieren, so daß diese nicht vom LSB von min abhängen. Diese Änderung, nach dem alten nicht angepaßten Algorithmus interpretiert, würde allerdings gewisse Artefakte erzeugen, die vermutlich als etwas stärkeres Rauschen sichtbar würden.

Provokante Frage: Würden wir es merken, wenn Sony etwas in dieser Art schon implementiert hätte und dcraw die Daten zwar immer noch plausibel, aber nicht mehr "korrekt" interpretiert, so daß die darauf basierenden Konverter z.B. aus SLT-A99-Dateien nicht alles rausholen, was drin ist?

- Was ist mit dem pathologischen Fall max = min? In diesem Fall wird ein Fenster der Höhe 0 aufgespannt. Der Algorithmus in der bisherigen Form ließe sich davon nicht beeindrucken und würde die restlichen 14 Rohdaten immer noch aus den 7-Bit-Daten generieren, obwohl doch eigentlich (zumindest kann man eine solche Implementierung in der Kamera wohl annehmen) bereits feststeht, welchen Wert sie haben.
Normalerweise müßten dann ja die 7-Bit-Werte auch alle 0 sein, aber was ist, wenn dies in real vorliegenden Daten nicht der Fall sein sollte? Hat schon mal jemand auf diese Bedingung im Debugger geprüft? Es wäre immerhin denkbar, daß die restlichen 14 mal 7 Bit-Daten dann anders zu interpretieren wären.
Sollte max = min gar häufiger vorkommen, könnte man dies auch als Sonderfall behandeln, um den Algorithmus zu beschleunigen (allerdings nur dann, wenn alle 7-Bit-Werte dann auch immer auf 0 bleiben).

ZITATAllerdings war cRAW auf jeden Fall bislang kein Hindernis - niemand hat je zeigen können, dass damit überhaupt irgendein Unterschied rauskommt. Es hängt eben doch von der Verteilung des Eingabekanals ab ob sich cRAW überhaupt "Verlustbehaftet" ausdrücken kann.[/quote]
Hier wird ein "echtes" 12-Bit-RAW mit dem cRAW-komprimierten Bild überlagert und die Unterschiede sichtbar gemacht:

http://www.dyxum.com/dforum/the-consolidat...230.html#316230
http://www.dyxum.com/dforum/the-consolidat...433.html#316433

Da dies natürlich nur auf der Basis des dcraw-Dekompressionsalgorithmus passiert, der, wie oben angedeutet, möglicherweise noch etwas an Qualität verschenkt (weil wir die genaue Implementierung des Kompressionsalgorithmus in der Kamera nicht kennen), ist das Ergebnis real eventuell etwas weniger ausgeprägt, aber das Bild zeigt in jedem Fall anschaulich, wo der cRAW-Algorithmus seine Schwächen hat (wobei das Motiv noch sehr gutmütig ist).
Angenommen, genau diese Bereiche würden nun in einer weiteren Verfeinerung des Verfahrens verlustfrei (ob unkomprimiert oder nach einem anderen Verfahren komprimiert) gespeichert, würde Sony mit geringem Mehraufwand auch eine tatsächlich verlustfreie Kompression realisieren können, die über jeden Zweifel erhaben ist.

Um nur mal ein Beispiel zu bringen, wie einfach man sowas implementieren könnte:

Enthalten max und min im Header den gleichen Wert, wird effektiv kein Fenster aufgespannt, der Algorithmus in der bisherigen Form also ad absurdum geführt (s.o.). Dieser Fall könnte dahingehend ausgelegt werden, daß die Daten in diesem 128-Bit-Block anders interpretiert werden müssen als sonst. Allerdings gingen dafür schon mal 2*11 Bits drauf, insgesamt würden aber 8 14-Bit-Werte (Verlust: 16 Bits, davon frei nutzbar: 5 Bits), 9 12-Bit-Werte (Verlust: 20 Bits, davon frei nutzbar: 9 Bits, es wären also auch 9 13-Bit-Werte realisierbar) oder 10 11-Bit-Werte (Verlust: 18 Bits, davon frei nutzbar: 7 Bits) in den Datenblock passen.

Alternativ und noch weniger verschwenderisch vielleicht die ebenfalls bisher nicht genutzte Bedingung, daß imax = imin ist (eine Bedingung, die in bisherigen Nutzdaten definitiv nicht vorkommen "darf", denn sonst würde der dcraw-Dekompressionsalgorithmus dahingehend versagen, daß er nämlich einen der 16 Werte des Blocks nicht initialisieren würde - dessen 7 Bits blieben dann ungenutzt und könnten im Prinzip eine andere Bedeutung haben), womit wir nur 2*4 Bit verschwenden, von denen wir 4 sogar wieder "recoveren" können, da es ja 16 Bitkombinationen gibt, die alle das Gleiche aussagen.
Dann würden ebenfalls nur 8 14-Bit-Werte (Verlust: 12 Bits, frei nutzbar, es wären also auch 8 15-Bit-Werte realisierbar), aber schon 10 12-Bit-Werte (Verlust: 4 Bits, frei nutzbar) oder 11 11-Bit-Werte (Verlust: 3 Bits, frei nutzbar) in den Datenblock passen.

Das könnte mit minimalem Aufwand ohne zusätzliche Ressourcennutzung in den bestehenden Kompressions- und Dekompressionscode integriert werden. Kameraseitig entstünde lediglich in einem Punkt Zusatzaufwand, nämlich zu erkennen, wann statt das bisherige Kompressionsverfahren anzuwenden die Daten nun einfach gespeichert werden sollten.

Der Kompressionsalgorithmus in der Kamera müßte also dahingehend verfeinert werden, daß er überwacht, ob Präzision verloren geht. Die Kamera würde dann einfach die laufende Kompression des aktuellen Datenblocks abbrechen und die vorliegenden Daten gemäß obiger Verteilung unkomprimiert wegspeichern.

Vielleicht übersehe ich hier irgendwas in dieser ad-hoc-Betrachtung, aber alle gängigen Prozessoren bieten z.B. diverse Flags an (z.B. Underflow, Overflow, Carry), die man geschickt abfragen kann, um zu erkennen, daß bei einer Operation z.B. ein Divisionsrest entstanden ist, was, wenn er im weiteren Verlauf unter den Tisch fällt, einen Genauigkeitsverlust bedeutet, den die Dekompression auf der anderen Seite nicht wieder zurückholen kann.

Da solche Informationen quasi als Abfallprodukt anfallen und entweder genutzt werden können oder eben nicht, sollte sich der zusätzliche Rechenaufwand dafür in engen Grenzen halten und keinesfalls den doppelten Aufwand ausmachen.
Auch ist das eine Operation, die sich sehr gut für eine Parallelisierung und Implementierung in Hardware-Logik eignen würde, bei der dann einfach der gleiche Datensatz nach verschiedenen Verfahren bearbeitet wird und nachher nur das beste Ergebnis übernommen wird.

Ich fände eine solche Verfeinerung des Verfahrens ziemlich erstrebenswert.

Viele Grüße,

Matthias

ZITAT(matthiaspaul @ 2013-01-09, 18:36) Hier wird ein "echtes" 12-Bit-RAW mit dem cRAW-komprimierten Bild überlagert und die Unterschiede sichtbar gemacht:[/quote]
Das würde ich nun absolut nicht ernst nehmen, denn nur wenige Posts vorher auf dyxum zeigt sich ja in "Such way they heve all green in one block and red and blue in another block. ", dass Shatun das cRAW Verfahren nicht mal ansatzweise durchdrungen hat. Was sollen da diese Bildchen zeigen?

BG Hans

Hans hat recht - ich erinnere mich auch an das krude Programm von Shatun. Sein Bildchen zeigt auch höchstens qualitativ grob wo Bitwerte verändert werden könnten, aber nicht quantitativ wie stark das sein wird. Außerdem müsste er eben auch um die reale Implementierung in der Kamera wissen, sonst ist das auch nur Vermutung. Leider ist dieser fehlende Baustein nach wie vor sehr unbefriedigend - so dass ich mittlerweile sogar darüber nachgedacht habe, ob man nicht den IDC mal disassemblieren könnte.

ZITAT(Neonsquare @ 2013-01-10, 22:15) ich erinnere mich auch an das krude Programm von Shatun.[/quote]
Hat er das denn irgendwo mal veröffentlicht? In dem entsprechenden Dyxum-Thread konnte ich keinen diesbezüglichen Link finden...
ZITATSein Bildchen zeigt auch höchstens qualitativ grob wo Bitwerte verändert werden könnten, aber nicht quantitativ wie stark das sein wird.[/quote]
Das ist absolut richtig.

Aber selbst wenn er ungenau arbeitet, gibt die Superposition doch, finde ich, wenigstens schon mal eine gute Vorstellung davon, wo das Verfahren potentiell an seine Grenzen kommt. Ich glaube, daß die meisten Mitleser unserer Diskussion hier ihre lieben Schwierigkeiten haben dürften, unseren Überlegungen nur anhand des Quelltextes einer Dekompressionsroutine zu folgen. Mit so einem Bildchen wird's schon viel anschaulicher, auch wenn das Ausmaß der Fehler im Detail nicht korrekt dargestellt wird (werden kann).
ZITATAußerdem müsste er eben auch um die reale Implementierung in der Kamera wissen, sonst ist das auch nur Vermutung.[/quote]
Ja.
ZITATLeider ist dieser fehlende Baustein nach wie vor sehr unbefriedigend - so dass ich mittlerweile sogar darüber nachgedacht habe, ob man nicht den IDC mal disassemblieren könnte.[/quote]
Das wäre zumindest einfacher, als die Firmware einer Kamera auseinanderzunehmen, aber trotzdem ein Riesenbatzen Arbeit...

Aber vorher würde ich den Dekompressionscode mal mit Debug-Code anreichern, der das Auftreten sämtlicher oben beschriebener Bedingungen (die, die eigentlich gar nicht vorkommen dürfen, und auch die, die nur etwas "grenzwertig" sind) anzeigt und wegloggt. Bei Dateien, die diesbezüglich auffällig geworden sind, lohnt es sich bestimmt, einfach mal ein paar Codevarianten auszuprobieren. Im direkten Vergleich alt gegen neu kann man u.U. eine leichte Qualitätszunahme erkennen oder auch das Gegenteil und könnte dann bestimmte Varianten verwerfen, andere hingegen genauer untersuchen.

Viele Grüße,

Matthias