RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#16 von weberhj , 12.01.2013 20:04

Hallo Matthias,

hab mir etwas Zeit genommen und habe die Dekodierung einiger meiner A900 arw Dateien unter kontrolle des Debuggers beobachtet...
ZITAT(matthiaspaul @ 2013-01-09, 18:36)

1
2
 
                  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.[/quote]
Diese Bedingung ist bei keiner meiner ARWs je eingetreten, dieses if könnte man sich also evtl. komplett sparen, es kostet aber auch nicht gerade viel Rechenzeit.

ZITAT(matthiaspaul @ 2013-01-09, 18:36) - 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?[/quote]
Dieser Fall max=min ist auch kein einziges mal in meinen ARWs aufgetreten, obwohl ich auch mit Absicht, eine um 4 Blenden unter- und überbelichtete ARW mit im Testpool hatte.

Ich denke es würde uns weiterbringen, wenn wir den Kamera internen Kodierungscode nachprogrammieren und dann auf unkomprimierte Sony A900 12-Bit ARWs und auf z.B. unkomprimierte Nikon oder Canon 14-Bit Raw-Daten die Sony Kodierung und Dekodierung anwenden und dann die so manipulirten Dateien nach der Bayer Interpolation von denen ohne diese beiden Zwischenschritte konvertierten Dateien abziehen. Denn schlussendlich kommt es ja darauf an, was es für Auswirkungen auf die für die Weiterbearbeitung benutzten 16 Bit Bilddateien hat.

BG Hans

Edit:
Kleiner Nachtrag. Die Funktion curve (pix[i]) liefert bei meinen Konvertierungen mit Sony ARWs immer curve (pix[i])=pix[i]).


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#17 von Neonsquare , 12.01.2013 21:41

ZITAT(Hans-J. @ 2013-01-12, 20:04) Ich denke es würde uns weiterbringen, wenn wir den Kamera internen Kodierungscode nachprogrammieren und dann auf unkomprimierte Sony A900 12-Bit ARWs und auf z.B. unkomprimierte Nikon oder Canon 14-Bit Raw-Daten die Sony Kodierung und Dekodierung anwenden und dann die so manipulirten Dateien nach der Bayer Interpolation von denen ohne diese beiden Zwischenschritte konvertierten Dateien abziehen. Denn schlussendlich kommt es ja darauf an, was es für Auswirkungen auf die für die Weiterbearbeitung benutzten 16 Bit Bilddateien hat.[/quote]

Ich sehe da allerdings ein Problem: Wir haben keinerlei Informationen darüber wie die 12 oder 14 Bit auf die 11 Bit im cRAW abgebildet werden. Gerade das ist jedoch eine absolut notwendige Information. Wir können natürlich selbst einen Algorithmus entwerfen, aber ob der sich dann genauso verhält ist schwer zu sagen - auch nicht inwiefern Kameraintern nicht noch weitere Informationen sich auf die Kodierung auswirken. Im Prinzip haben wir es mit einer Interpolation bzw. Approximation zu tun - aber wie diese funktioniert kann sehr stark variieren - mit deutlich unterschiedlichen Folgen.

Wo ich ein reenginering der cRAW-Dekodierung noch für erreichbar halte, so ist denke ich die cRAW-Kodierung nur äußerst schwierig erreichbar.


Neonsquare  
Neonsquare
Beiträge: 358
Registriert am: 05.03.2010


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#18 von weberhj , 12.01.2013 22:39

ZITAT(Neonsquare @ 2013-01-12, 21:41) Ich sehe da allerdings ein Problem: Wir haben keinerlei Informationen darüber wie die 12 oder 14 Bit auf die 11 Bit im cRAW abgebildet werden. Gerade das ist jedoch eine absolut notwendige Information. Wir können natürlich selbst einen Algorithmus entwerfen, aber ob der sich dann genauso verhält ist schwer zu sagen - auch nicht inwiefern Kameraintern nicht noch weitere Informationen sich auf die Kodierung auswirken.[/quote]
Mathematische Exaktheit können wir für den Kodierungsalgorithmus ohne den originalen Quellcode natürlich nicht garantieren, aber nachdem er doch sehr, sehr simpel aufgebaut ist halte ich die Wahrscheinlichkeit, dass wir uns bis auf einen evtl. Rundungsfehler im niederwertigsten Bit an den Kamera internen Algorithmus annähern können für relativ hoch.

Bisher deutet ja auch wirklich nichts darauf hin, dass z.B. in irgendwelchen Metadaten noch die zusätzlichen 2 Bit stecken könnten.

Ich bin mir auch ziemlich sicher, dass Coffin nicht für alle möglichen Kamerafabrikate im "reverse engineering" Verfahren die Formate dekodiert hat, ich vermute auch aus "gewissen" anderen Gründen eine Zusammenarbeit mit den Kameraherstellern. Einige der Konvertierungsparameter von dcraw sind z.B. auch in Adobe ACR immer wiedeer aufgetaucht. Ich vermute daher einige "enge" Kontakt von Herstellern hin zu Coffin, der mit seinem Quellcode dann zumindest eine konzeptionelle Vorlage für so manches kommerzielle Produkt abgibt.

BG Hans


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#19 von matthiaspaul , 13.01.2013 13:50

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]

ZITAT(Hans-J. @ 2013-01-12, 20:04) Kleiner Nachtrag. Die Funktion curve (pix[i]) liefert bei meinen Konvertierungen mit Sony ARWs immer curve (pix[i])=pix[i]).[/quote]
Das deckt sich ja mit dem, was 2008 auch schon in dem Dyxum-Thread geschrieben wurde, damals war das Feld curve[] einfach linear mit Werten von 0..4000h belegt (also 14 Bit breit) und wurde offenbar nur bei Nikon-Kameras mit anderen Werten belegt. (Den Teil des Codes habe ich mir jetzt noch nicht angeschaut.) Enthalten die ARW-Dateien denn keine individuelle Definition einer solchen Kurve?

Die derzeit maximal 11-bittigen Daten, die aus der Dekompressionsroutine purzeln, werden hier also effektiv hart auf 10 Bit gestutzt, indem einfach das LSB verworfen wird. Es findet noch nicht einmal Dithering o.ä. statt.

Kommt die spätere Bayer-Interpolation denn mit 11- und mehrbittigen Daten nicht klar? (Habe ich mir ebenfalls noch nicht angeschaut.) Falls doch, müßte die folgende Modifikation doch schon mal 1 Bit genauere Werte liefern:

1
2
 
                        for (i=0; i < 16; i++, col+=2)
                           RAW(row, col) = curve[pix[i] << 1] >> 2;
 


1
2
 
                        for (i=0; i < 16; i++, col+=2)
                           RAW(row, col) = curve[pix[i]];
 



EDIT: Ein Vergleich mit der "alten" 12-Bit-RAW-Routine zeigt, daß RAW(row, col) zumindest 12-bittige Werte noch akzeptiert (was aber noch nicht bedeutet, daß größere Werte nicht erlaubt wären):

1
2
3
4
5
6
7
8
9
10
 
void CLASS sony_arw_load_raw()
{
[...]
         if ((sum += diff) >> 12)
            derror();
 
         if (row < height)
            RAW(row, col) = sum;
[...]
}
 


Solange curve[] also nur 1:1-Werte liefert (gibt es Bedingungen, unter denen das mit irgendeiner der bisherigen Kameramodelle nicht gilt?), müßte

1
2
 
                        for (i=0; i < 16; i++, col+=2)
                           RAW(row, col) = curve[pix[i]];
 


eigentlich funktionieren, ja sich sogar wie folgt beschleunigen lassen:

1
2
 
                        for (i=0; i < 16; i++, col+=2)
                           RAW(row, col) = pix[i];
 


Vermutlich muß man dafür noch irgendwo anders einen Skalierungsfaktor anpassen, aber eben erst später.

Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)


matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#20 von matthiaspaul , 13.01.2013 17:51

Auch interessant:

http://www.rawdigger.com/node/180
ZITATZITAT
Submitted by Michael Phillips (not verified) on Tue, 2012-11-13 - 11:41

I was using rawdigger to look at my a99 raw files. The 0.9.12 version displayed all histograms with 4000 levels and the 0.9.13 version now displays all histograms with 16300 levels, even the 12 bit raw files!

Am I missing a point here or is the a99 not fully supported yet?[/quote]
Submitted by lexa on Tue, 2012-11-13 12:33:

The A99 is 'partially' supported: no automatic black level calculation, while raw data is decoded OK.The difference is in 'ARW2 Hack' setting (scaling/not scaling data from Sony cameras to 0-16383 range): - in 0.9.12 this setting is default to 'Off' - in 0.9.13 defaults is to use RAWspeed library for faster decoding. This setting implies ARW2 Hack to On.
[/quote]
und

http://www.rawdigger.com/comment/4426#comment-4426
ZITATZITAT
Submitted by tesilab on Thu, 2012-12-27 16:03:

After experiencing some unwanted posterization with light processing, I took my RX1 raw files, and compared against files I have found on the web for A99 and D600 (and D3). What I found with raw digger is that my most sample-rich raw file contains only 1530 unique values on a scale of 0-4093 (93!, rather than something more like approximately 0-16383, I was expected. The values were continuous from 0-800, with about 320 only 320 unique values in the 801-1424 range, and only 258 unique values in the 2030-4093 range. The A99 sample I found was similar, and the Nikon files I found (same daylight scene, all base ISO, EV-0, btw) showed 14 bits worth of data, unlike the Sony.

Is this explained somehow by only Raw digger only partially decoding the ARW files (lower order bits), or is there a real difference here?[/quote]
Submitted by lexa on Tue, 2013-01-01 02:55:

For Sony A99/RX1 the '14 bit' clause corresponds only to data range.

The data precision is another story: only 1/8 of pixels are stored with 11-bit precision, while remaining 7/8 of pixels are stored with 7-bit precision.

I've wrote small article about Sony 'ARW2' format. Unfortunately, it is in Russian, you may try Google translate to read it. It is here:

http://blog.lexa.ru/2012/12/29/o_sortakh_raw_u_sony.html.

I'll translate this article to English sometimes in future (1-2 week I hope)
[/quote]
In diesem Code-Schnipsel aus RawLibs RawSpeed-Bibliothek, die von RawDigger verwendet wird und der Dekompressionsroutine in dcraw nachempfunden ist, ist die Division durch 2, durch die ein Bit Genauigkeit verloren geht, bereits rausgeflogen, allerdings wohl in erster Linie aus Geschwindigkeitsgründen. Auch die völlig unnötige Zwischenspeicherung der 16 dekomprimierten Werte in einem lokalen Feld ist rausgeflogen, was ebenfalls eine höhere Verarbeitungsgeschwindigkeit bringt. Algorithmisch hält sich der Code noch ans Vorbild dcraw.
http://blog.lexa.ru/2012/12/29/o_sortakh_raw_u_sony.html.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
 
   // Process 32 pixels (16x2) per loop.
   for (uint32 x = 0; x < w - 30;) {
 
      bits.checkPos();
 
      int _max = bits.getBits(11);
      int _min = bits.getBits(11);
      int _imax = bits.getBits(4);
      int _imin = bits.getBits(4);
 
      int sh;
 
      for (sh = 0; sh < 4 && 0x80 << sh <= _max - _min; sh++);
 
      for (int i = 0; i < 16; i++) {
 
         int p;
 
         if (i == _imax) p = _max;
         else
            if (i == _imin) p = _min;
            else {
               p = (bits.getBits(7) << sh) + _min;
               if (p > 0x7ff)
                  p = 0x7ff;
            }
            dest[x+i*2] = curve[p << 1];
      }
      x += x & 1 ? 31 : 1;  // Skip to next 32 pixels
   }
 


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)


matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#21 von weberhj , 19.01.2013 14:43

Die Sache lies mir jetzt doch keine Ruhe und ich bin heute spontan mal in "Vorleistung" gegangen...
Ich hatte vor einigen Jahren schon mal, nur für mich im Debugger, eine Testversion von dcraw zur Analyse des ARW2 entwickelt und habe sie jetzt mal auf allgemeine Verwendung umgeschrieben...

Also, entstanden ist eine dcraw_hjwARW2EnDecode.exe (9.17 also die derzeit aktuelle Version) die um den Kommandozeilenparameter:
-_
( minus underscore) erweitert wurde. Wird dieser gesetzt durchläuft dcraw nach dem einlesen der RAW Daten zusätzlich folgende unten angehängte Funktion ARW2EnDecode ():
Ich würde alle interressierten Mitstreiter darum bitten mal ein schnellen Blick darauf zu werfen und evtl. Verbesserungsvorschläge vorzutragen, ich werde sie nach prüfung gerne einarbeiten.
Insbesondere die Encodierung (in Anlehnung zu dem in Sony Kameras verwendeten Algorithmus) der Daten beruht bislang lediglich auf meinen Annahmen.

Was kann man nun mit dieser speziellen Testversion machen?

Man kann damit Raw-Daten aus z.B. Nikon 14-Bit NEF Dateien mit dieser Option bereits vor der Bayer Interpolation durch den dem Sony ARW2 Kompressionsalgorithmus zumindest qualitativ sehr ähnlichen Algorithmus laufen lassen und mit einem ohne diesen Zwischenschritt konvertierten Bild vergleichen.

z.B.
dcraw_hjwARW2EnDecode -T -6 -v D600hSLI00100NR0.NEF // liefert eine 16 Bit Tiff Datei wie jede andere dcraw Version auch
dcraw_hjwARW2EnDecode -T -6 -v -_ D600hSLI00100NR0.NEF // liefert ebenfalls eine 16 Bit Tiff Datei, die RAW Daten wurden jedoch vor der Bayer Interpolation durch die ARW2 ähnliche EnDekodierung geschickt.

Das gleiche kann man z.B. auch mit 12-Bit A900 Raw Dateien machen, die nicht mit ARW2 komprimiert abgespeichert sind, typischerweise alle A900 ARWs mit mehr als 30MB:

dcraw_hjwARW2EnDecode -T -6 -v AA900hSLI1600_NR_OFF.ARW
dcraw_hjwARW2EnDecode -T -6 -v -_ AA900hSLI1600_NR_OFF.ARW

(Beide genannten Raw Dateien kann man bei imaging-resource.com kostenlos herunterladen.)

In Potoshop kann man dann z.B. mit einem überlagerten Differenz-Layer z.B. vom Originalbild das ARW2EnDecode Bild abziehen um sich ein Bild von den Veränderungen durch die bisher von mir implementierte ARW2 ähnliche Komperssion zu machen.

Bevor ich in die Bildanalyse gehe, hätte ich aber gerne erst noch Eure Kommentare zu meinem Code-Vorschlag eingeholt, denn es ist wirklich nur ein schneller Hack, eher auf Lesbarkeit getrimmt und noch in keinster Weise optimiert.

Anmerkung: Das hochladen einer .Exe Datei ist mir hier nicht gestattet, vielleicht kann Matthias oder ein anderer Admin da helfen?

BG Hans

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
 
void ARW2EnDecode() // hjw 2013-01-19
{
    /*
        hjw assuming raw image available in:
        raw_image[(row)*raw_width+(col)]
        
        and also necessary:
        raw_width, raw_height, tiff_bps = 12 || 14
    */
 
    unsigned int i, row, col, max_c1, min_c1, imax_c1, imin_c1, max_c2, min_c2, imax_c2, imin_c2, range, shift_c1, shift_c2;
    unsigned int c1[16], c2[16];                    // 16 horizontal color pixel neighbors of same color for two colors (e.g.: green, red)
    unsigned int EnDecode_c1[16], EnDecode_c2[16];    // the new values (after hjws ARW2 en- decoding) for both colors
 
    // skip processing if bit depth is not supported
    if (!(tiff_bps == 12 || tiff_bps == 14)) {
        printf ("Error in ARW2EnDecode: value of tiff_bps is not 12 or 14 -> not supported, function ARW2EnDecode aborts!");
        return;        
    }
 
    // Print some debug information
    printf ("raw_width: %d \n", raw_width);
    printf ("raw_height: %d \n", raw_height);
    printf ("Original 2x16 values of first 32 Pixels:\n");
    for (i=0; i<32; i=i+2) printf ("raw_image[%u]: %d raw_image[%u]: %u \n", i, raw_image[i], i+1, raw_image[i+1]);
 
    // fetch raw data
    for (row = 0; row < raw_height; row++)                            // loop over all rows of bayer raw image data
        for (col = 0; col < raw_width-32; col += 32) {                    // loop over all columns of bayer raw image data
            for (i=0; i<=15; i++) {
                c1[i] = raw_image[row*raw_width + col + (i<<1)];            // fetch 16 Pixel of first color
                c2[i] = raw_image[row*raw_width + col + (i<<1) + 1];        // fetch 16 Pixel of second color
            }
 
            // cut down 14 bits to 12 bit resolution if necessary (e.g.: Nikon, Canon...)
            if (tiff_bps==14)
                for (i=0; i<=15; i++) {
                    c1[i] = c1[i] >> 2;            
                    c2[i] = c2[i] >> 2;            
                }
 
// encode data, only my (hjw) guess, I hope to come close to Sonys original ARW2 encoding algorithm
            // calculate min, max, imin, imax for both colors
            max_c1 = 0; max_c2 = 0; min_c1 = 0xffffffff; min_c2 = 0xffffffff;
            for (i=0; i<16; i++) {
                if (max_c1 < c1[i]) {max_c1 = c1[i]; imax_c1=i;}
                if (min_c1 > c1[i]) {min_c1 = c1[i]; imin_c1=i;}
 
                if (max_c2 < c2[i]) {max_c2 = c2[i]; imax_c2=i;}
                if (min_c2 > c2[i]) {min_c2 = c2[i]; imin_c2=i;}
            }
            
            // calculate shift values as f(max-min)
            range = (max_c1>>1) - (min_c1>>1);            // window range from 11 bit max min values
            if (range < 128) shift_c1=0;                // for first color
            else if (range < 256) shift_c1=1;
                 else if (range < 512) shift_c1=2;
                      else if (range < 1024) shift_c1=3;
                           else shift_c1=4;
            range = (max_c2>>1) - (min_c2>>1);            
            if (range < 128) shift_c2=0;                // and for second color too
            else if (range < 256) shift_c2=1;
                 else if (range < 512) shift_c2=2;
                      else if (range < 1024) shift_c2=3;
                           else shift_c2=4;
 
            // calculate remaining 7 bit values
            for (i=0; i<16; i++) {
                if ((i!= imax_c1) && (i!= imin_c1)) {        // for first color
                    c1[i] = (c1[i]-min_c1) >> shift_c1;
                }
                if ((i!= imax_c2) && (i!= imin_c2)) {        // and for second color too
                    c2[i] = (c2[i]-min_c2) >> shift_c2;
                }
            }
 
// decode data immediatly again
            max_c1 = max_c1 & 0xfffe; max_c2 = max_c2 & 0xfffe; // from encoded ARW2 files we only get 11 Bit values -> wipe out lowest bit
            min_c1 = min_c1 & 0xfffe; min_c2 = min_c2 & 0xfffe;
 
            for (i=0; i<16; i++) {                              
                if (i == imax_c1) EnDecode_c1[i]= max_c1;        // for first color
                else if (i == imin_c1) EnDecode_c1[i]= min_c1;
                     else EnDecode_c1[i]= min_c1 + (c1[i] << shift_c1);
 
                if (i == imax_c2) EnDecode_c2[i]= max_c2;        // same for second color too
                else if (i == imin_c2) EnDecode_c2[i]= min_c2;    
                     else EnDecode_c2[i]= min_c2 + (c2[i] << shift_c2);
            }
 
            // write EnDeCoded data back to bayer raw_image array            
            for (i=0; i<16; i++) {
                if (tiff_bps==14) {                            // expand back to 14 Bit if original was 14 Bit for further bayer interpolation
                    EnDecode_c1[i] = EnDecode_c1[i] << 2;
                    EnDecode_c2[i] = EnDecode_c2[i] << 2;
                }
                raw_image[row*raw_width + col + (i<<1)] = EnDecode_c1[i];            // write back 16 EnDecoded Pixels of first color
                raw_image[row*raw_width + col + (i<<1) + 1] = EnDecode_c2[i];        // write back 16 EnDecoded Pixels of second color
            }
        }
 
    // Print some debug information
    printf ("New values:\n");
    for (i=0; i<32; i=i+2) printf ("raw_image[%u]: %d raw_image[%u]: %u \n", i, raw_image[i], i+1, raw_image[i+1]);
}
 


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#22 von Neonsquare , 19.01.2013 14:58

ZITAT(Hans-J. @ 2013-01-19, 14:43) Die Sache lies mir jetzt doch keine Ruhe und ich bin heute spontan mal in "Vorleistung" gegangen...
Ich hatte vor einigen Jahren schon mal, nur für mich im Debugger, eine Testversion von dcraw zur Analyse des ARW2 entwickelt und habe sie jetzt mal auf allgemeine Verwendung umgeschrieben...

...

Bevor ich in die Bildanalyse gehe, hätte ich aber gerne erst noch Eure Kommentare zu meinem Code-Vorschlag eingeholt, denn es ist wirklich nur ein schneller Hack, eher auf Lesbarkeit getrimmt und noch in keinster Weise optimiert.[/quote]

Ich bin ja immer noch skeptisch, ob das Ergebnis vergleichbar ist. Zumindest dürfte es ein wenig besser als "< /dev/random" sein - also interessiert mich Deine Bildanalyse durchaus. Trotzdem möchte ich noch einmal zu Bedenken geben, dass es sich hier um einen _angenommenen_ Algorithmus geht und das die Realität ziemlich deutlich abweichen könnte. Also nicht gleich auf die Barrikaden steigen, falls die Ergebnise "empörend" sind ;-)


Neonsquare  
Neonsquare
Beiträge: 358
Registriert am: 05.03.2010


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#23 von weberhj , 19.01.2013 15:07

ZITAT(Neonsquare @ 2013-01-19, 14:58) Ich bin ja immer noch skeptisch, ob das Ergebnis vergleichbar ist. Zumindest dürfte es ein wenig besser als "< /dev/random" sein - also interessiert mich Deine Bildanalyse durchaus. Trotzdem möchte ich noch einmal zu Bedenken geben, dass es sich hier um einen _angenommenen_ Algorithmus geht und das die Realität ziemlich deutlich abweichen könnte. Also nicht gleich auf die Barrikaden steigen, falls die Ergebnise "empörend" sind ;-)[/quote]
Da kann ich dich beruhigen, die Differenzbilder sind nahezu schwarz...

BG Hans


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#24 von matthiaspaul , 19.01.2013 16:54

ZITAT(Hans-J. @ 2013-01-19, 14:43) Die Sache lies mir jetzt doch keine Ruhe und ich bin heute spontan mal in "Vorleistung" gegangen...
Ich hatte vor einigen Jahren schon mal, nur für mich im Debugger, eine Testversion von dcraw zur Analyse des ARW2 entwickelt und habe sie jetzt mal auf allgemeine Verwendung umgeschrieben...

Also, entstanden ist eine dcraw_hjwARW2EnDecode.exe (9.17 also die derzeit aktuelle Version) die um den Kommandozeilenparameter:
-_
( minus underscore) erweitert wurde.[/quote]
Prima.
ZITATBevor ich in die Bildanalyse gehe, hätte ich aber gerne erst noch Eure Kommentare zu meinem Code-Vorschlag eingeholt, denn es ist wirklich nur ein schneller Hack, eher auf Lesbarkeit getrimmt und noch in keinster Weise optimiert.[/quote]
Egal, darauf kommt es ja (erstmal) nicht an.

Hatte noch keine Zeit, Deine Routine zu studieren, schaue mir diese aber nachher an.
ZITATAnmerkung: Das hochladen einer .Exe Datei ist mir hier nicht gestattet, vielleicht kann Matthias oder ein anderer Admin da helfen?[/quote]
Direkt binär ausführbare Dateitypen lassen wir aufgrund des generellen Sicherheitsrisikos, das damit verbunden ist, nicht zu, aber wenn Du die Datei als ZIP packst, müßte es gehen. Sollte die Quota nicht reichen, gibt mir bitte Bescheid, dann setze ich die hoch.

Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)


matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#25 von weberhj , 19.01.2013 17:06

Danke Matthias,

ZITAT(matthiaspaul @ 2013-01-19, 16:54) Direkt binär ausführbare Dateitypen lassen wir aufgrund des generellen Sicherheitsrisikos, das damit verbunden ist, nicht zu, aber wenn Du die Datei als ZIP packst, müßte es gehen. Sollte die Quota nicht reichen, gibt mir bitte Bescheid, dann setze ich die hoch.[/quote]
danke für die Info, anbei die ZIP.

BG Hans


In the mind of Minolta...

Dateianlage:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden!
f286t33038p294148n1.zip

weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#26 von matthiaspaul , 19.01.2013 17:33

Bei der Gelegenheit kippe ich doch direkt noch eine leicht überarbeitete Fassung der normalen Dekompression ab, die hier seit letzter Woche im Editor hängt (allerdings ungetestet, da ich auf diesem Rechner keinen C-Compiler habe). Die zusätzlichen Debug-Ausgaben helfen vielleicht dabei, auf Besonderheiten in den Daten zu stoßen, die man dann genauer untersuchen kann. Funktionale Änderungen betreffen nur kleine Optimierungen (mehr wäre möglich, liegen aber erstmal nicht im Fokus), das 16-Werte-Array und die unnütze Shift-Abfrage ist rausgeflogen. Soweit sollte der Code identische Ergebnisse liefern. Das künstliche Clipping bei 7FFh ist auch nicht mehr drin, pdata kann also theoretisch 12-bittig werden. Damit bekommt curve[] also maximal 13-bittige Werte als Index, gegenüber 12-Bit-Werten zuvor. Sollte der Fall je vorkommen, müßte er eigentlich durch die Kurvendefinition selbst aufgefangen werden (können). Vermutlich ist der Kurvenverlauf für curve[] derzeit einfach für 12 Bit optimiert. (Zur Kamerakurve komme ich später sowieso nochmal.)

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
 
#define DEBUG 1
#define OLD 1
 
void CLASS sony_arw2_load_raw&#40;&#41;
{
&nbsp;&nbsp; uchar *data, *dp; // pointers into compressed raw data line buffer
&nbsp;&nbsp; ushort pdata;&nbsp;&nbsp;&nbsp;&nbsp; // uncompressed raw value &#40;11 bits used, expandable up to 15 bits
&nbsp;&nbsp; int row, col, val, max, min, imax, imin, sh, bit, i; // these are signed 32-bit variables
&nbsp;&nbsp;
&nbsp;&nbsp; data = &#40;uchar *&#41; malloc&#40;raw_width&#41;;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// allocate memory for one raw data line
&nbsp;&nbsp; merror &#40;data, &#34;sony_arw2_load_raw&#40;&#41;&#34;&#41;; // bail out on allocation errors
 
&nbsp;&nbsp; for &#40;row=0; row &#60; height; row++&#41; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// run through lines of compressed raw data
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fread&#40;data, 1, raw_width, ifp&#41;;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// read compressed raw data into line buffer
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for &#40;dp=data, col=0; col &#60; raw_width-30; dp+=16&#41; { // run through columns in line buffer,
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // process 16 bytes &#40;128 bits&#41; in one go
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // evaluate header of compressed cluster of pixel data by getting 32 bit value from buffer
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; max = 0x7FF &amp; &#40;val = sget4&#40;dp&#41;&#41;; // max is bits 10&#46;&#46;0 &#40;11 bits for 0&#46;&#46;2047&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; min = 0x7FF &amp; val &#62;&#62; 11;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // min is bits 21&#46;&#46;11 &#40;11 bits for 0&#46;&#46;2047&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; imax = 0x0F &amp; val &#62;&#62; 22;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // imax is bits 25&#46;&#46;22 &#40;4 bits for 0&#46;&#46;15&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; imin = 0x0F &amp; val &#62;&#62; 26;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // imin is bits 29&#46;&#46;26 &#40;4 bits for 0&#46;&#46;15&#41;
 
#if DEBUG
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if &#40;imax == imin&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// must not occur as we cannot correctly decode it&#46; May indicate &#34;hidden data&#34;&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; Unknown ARW data header format near 0x%llx&#46;&#092;n&#34;&#41;, dp&#41;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if &#40;max == min&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// may theoretically occur in data, but is unusual and may indicate &#34;hidden data&#34;&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; Unusual data in ARW data header near 0x%llx&#58; Window size zero&#46;&#092;n&#34;&#41;, dp&#41;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if &#40;max &#60; min&#41;&nbsp;&nbsp;&nbsp;&nbsp;// must not occur, as we cannot correctly decode it&#46; May indicate &#34;hidden data&#34;&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; Unusual data in ARW data header near 0x%llx&#58; Negative window size&#46;&#092;n&#34;&#41;, dp&#41;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if &#40;max-min &#60; 64&#41; // may occur in data, but is unusual as smallest window size for 7-bit data is 128&#46; May indicate &#34;hidden data&#34;&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; Unusual data in ARW data header near 0x%llx&#58; Tiny window size&#46;&#092;n&#34;&#41;, dp&#41;;
#endif
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // bits 31 and 30 remain unused for header, but will be used for pixel data further below
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // max and min define highest and lowest margins in compressed cluster of 16 pixel data values&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 11 bits allow values of 0&#46;&#46;2047 at most
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // imax and imin define which 2 data values in compressed cluster correspond with margin values
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // 4 bits are sufficient as an index into 16 pixel data values contained in cluster
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // determine bit width of window of values &#40;max-min&#41; in compressed pixel data cluster
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for &#40;sh=0; 0x80 &#60;&#60; sh &#60;= max-min; sh++&#41;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // sh is 0 for window of 128, 1 for 256, 2 for 512, 3 for 1024, 4 for 2048 possible values
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // values &#62; 4 cannot occur with max/min being 11-bit values, but may be supported in the future
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // decompress 16 pixel data values from following 128-30 bit cluster in line buffer
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; for &#40;bit=30, i=0; i &#60; 16; i++, col+=2, bit += 7&#41; { // start at bit 30 in 128 bit cluster
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;i == imax&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// is highest value in cluster?
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; pdata = max;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // not stored inline, take from header as 11-bit
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if &#40;i == imin&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // is lowest value in cluster?
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pdata = min;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// not stored inline, take from header as 11-bit
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // remaining 14 data values are stored inline as 7-bit values
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;pdata = &#40;&#40;sget2&#40;dp+&#40;bit &#62;&#62; 3&#41;&#41; // get sliding window of 16 bits from line buffer
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#62;&#62; &#40;bit &amp; 7&#41; // zero-align currently relevant 7 bits
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&amp; 0x7F&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// strip off other bits, lowest 7 bits make up value now
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&#60;&#60; sh&#41;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // blow up in proportion to window size
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // &#40;times 1 for 7, 2 for 8, 4 for 9, 8 for 10, 16 for 11 bits&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;+ min;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; // offset to low margin of window
 
#if DEBUG
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;pdata &#62; max&#41; // may theoretically occur in data, but is unusual and may indicate &#34;hidden data&#34;&#46;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; ARW data decompression resulted in data outside window near 0x%llx&#58; &#46;&#092;n&#34;&#41;, dp&#41;;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;pdata &#62; 0x7FF&#41; // Unusual condition, but not necessarily invalid, therefore no reason to clip
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; fprintf&#40;stderr, _&#40;&#34;DEBUG&#58; ARW data decompression resulted in 12-bit rather than 11-bit value near 0x%llx&#46;&#092;n&#34;&#41;, dp&#41;;
#endif
 
#if OLD // let&#39;s keep it this way for now for compatibility with existing code
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RAW&#40;row, col&#41; = curve&#91;pdata &#60;&#60; 1&#93; &#62;&#62; 2; // apply camera curve and store in raw picture buffer
#else
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;RAW&#40;row, col&#41; = curve&#91;pdata&#93;; // apply camera curve and store in raw picture buffer
#endif
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// store resulting raw value away as 2 bytes in raw picture buffer
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// &#40;RAW macro addresses bytes in buffer, hence we must increment col by 2&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; col -= &#40;col &amp; 1&#41; ? 1&#58;31; // substract 1 if column odd, 31 if even
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp; }
&nbsp;&nbsp; free&#40;data&#41;; // free previously allocated memory
}
 



Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)


matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#27 von weberhj , 26.01.2013 23:56

Obwohl die ganze Thematik offensichtlich nicht auf besonders großes Interesse stößt (die Anzahl der Verbesserungsvorschläge an meinem vorgeschlagenen EnDecodeARW2-Algorithmus hält sich mit bisher exakt ==0 doch sehr im Rahmen) möchte ich die Auswirkungen auf das finale Bild hier doch noch an einem typischen Beispiel darstellen (ich habe inzwischen selbst doch eine ganze Reihe von Beispielen analysiert).

Dazu habe ich am Vormittag einen Stadl mit der A900 als 12-Bit Raw (meine Canon 40D 14Bit Aufnahmen und auch Nikon D600 14Bit Aufnahmen von imaging resource zeigen praktisch identisches Verhalten) aufgenommen:

Hier zunächst das komplette Bild:
[attachment=12292:2_DSC087...Schuppen.jpg]

Als 100% Crop sieht der mit einem Rahmen versehenen Ausschnitt so aus:
[attachment=12293:2_DSC087...pen_crop.jpg]

Daraufhin habe ich die 12Bit A900 Raw Datei (ohne ARW2 Kompression) zwei mal durch die oben zur Verfügung gestellte spezielle dcraw Programmdatei in 16 Bit TIFFs konvertieren lassen, einmal mit den Parametern -T -6 und das zeite mal mit den Parametern -T -6 -_. Bei der zweten Konvertierung durchlaufen die 12Bit Werte der A900 also die von mir oben abgedruckte Routine EnDecodeARW2().
Daraufhin habe ich beide TIFF Dateien in PS5 geladen, in der ersten eine Ebene (Option Differenz) hinzugefügt und die zweite Bilddatei mit dem Rechteck Auswahl Werkzeug kopiert und in die neue Ebene der ersten Datei einkopiert. Das Ergebnis sieht zunächst nahezu schwarz aus. Ich habe dann mit dem Tonwert Werkzeug die Obergrenze von 255 auf 15 herabgesetzt also um +4EV bzw. 4 Blenden aufgehellt. Das ist das Ergebnis bei eben genau demselben 100% Crop:
[attachment=12294:2_DSC087...___6_4EV.jpg]

Ein Vergleich mit dem weiter oben abgebildeten Blatt zeigt wie unzulässig diese hypothetische Annahme war.

Beim Vergleich der konvertierten Bilddateien vermag ich selbst beim direkten hin- und herschalten in 100% Ansicht praktisch keine Unterschiede zu erkennen, die Bayer Interpolation scheint also, wie erwartet, wieder einiges zu nivellieren.

BG Hans


In the mind of Minolta...

Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden!
 f286t33038p294389n1.jpg   f286t33038p294389n2.jpg   f286t33038p294389n3.jpg 

weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#28 von matthiaspaul , 27.01.2013 17:02

ZITAT(Hans-J. @ 2013-01-26, 23:56) Obwohl die ganze Thematik offensichtlich nicht auf besonders großes Interesse stößt (die Anzahl der Verbesserungsvorschläge an meinem vorgeschlagenen EnDecodeARW2-Algorithmus hält sich mit bisher exakt ==0 doch sehr im Rahmen) möchte ich die Auswirkungen auf das finale Bild hier doch noch an einem typischen Beispiel darstellen (ich habe inzwischen selbst doch eine ganze Reihe von Beispielen analysiert).[/quote]
Bei mir ist das nur ein Zeitproblem, kein Interessensproblem.

Ich habe es gerade nochmal versucht, aber die obige ZIP-Datei enthält eine JPG-Datei. Dem Counter 2 nach zu urteilen hat das außer mir noch niemand runtergeladen, aber daran wären wohl sonst einige Interessenten gescheitert. Die Datei muß vor der Ausführung in .EXE umgenannt werden.

An Deinem Algorithmus sind mir verschiedene Dinge aufgefallen, die noch nicht ganz "wasserdicht" sind:

- Mit 15- oder 16-bittigen Eingangsdaten würde der Algorithmus nicht arbeiten.

- Da der Dekompressionsalgorithmus ja mit 11-bittigen Daten arbeitet, sollten auch die Eingangsdaten in den Kompressionsalgorithmus auf 11 Bit runtergedrückt werden (notfalls durch Clipping), um formale Vergleichbarkeit zu erreichen - jedenfalls bei diesem ersten Kompressionsalgorithmus, der ja erstmal nur den bekannten Dekompressor 1:1 widerspiegelt. (Für spätere Varianten des Algorithmus habe ich Ideen, wie man tatsächlich 12- (oder auch 14-)bittige Eingangsdaten im Rahmen der vorhandenen 128-Bit-Datenstruktur und des vorhandenen Dekompressors bildorientiert besser verarbeiten kann, als einfach 11 Bit zu forcieren, aber das würde möglicherweise nicht offiziell gewünschte Seiteneffekte des dcraw-Dekompressors ausnutzen, deshalb denke ich, sollten wir das erst angehen, wenn der Basisalgorithmus 100% steht.)

- Die Index- und Fenstervariablen werden in pathologischen Fällen (z.B. alles 0) nicht richtig initialisiert, was zu einer falschen Datenverarbeitung führt.

- Die "7-Bit-Werte" können in Deinem Algorithmus tatsächlich 8-bittig werden, was zunächst nicht auffällt, da die Dekompression direkt damit weiterarbeitet. Aber es schafft natürlich andere Verhältnisse.

Die skizzierten (nicht auf Effizienz optimierten) Änderungen würden das vermeiden (Deine Dekompression müßte natürlich ebenfalls entsprechend angepaßt werden, aber soweit bin ich noch nicht "durch":

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
 
#define PATCH 1
 
&#91;&#46;&#46;&#46;&#93;
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// cut down 14 bits to 12 bit resolution if necessary &#40;e&#46;g&#46;&#58; Nikon, Canon&#46;&#46;&#46;&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;tiff_bps == 14&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for &#40;i=0; i&#60;=15; i++&#41; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;i&#93; = c1&#91;i&#93; &#62;&#62; 2;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;i&#93; = c2&#91;i&#93; &#62;&#62; 2;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
#if PATCH
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for &#40;i=0; i&#60;16; i++&#41; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;i&#93; &#62;&#62;= 1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// reduce 12-bit values to 11-bit
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;c1&#91;i&#93; &#62; 0x7FF&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;i&#93; = 0x7FF;&nbsp;&nbsp;// clip to 11-bit if necessary &#40;only possible for 15/16-bit input data&#41;
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;i&#93; &#62;&#62;= 1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// reduce 12-bit values to 11-bit
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;c2&#91;i&#93; &#62; 0x7FF&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;i&#93; = 0x7FF;&nbsp;&nbsp;// clip to 11-bit if necessary &#40;only possible for 15/16-bit input data&#41;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
#endif
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// encode data, only my &#40;hjw&#41; guess, I hope to come close to Sonys original ARW2 encoding algorithm
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// calculate min, max, imin, imax for both colors
#if PATCH
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imin_c1 = imin_c2 = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imax_c1 = imax_c2 = 1;
#endif
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;max_c1 = 0; max_c2 = 0; min_c1 = 0xffffffff; min_c2 = 0xffffffff;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for &#40;i=0; i&#60;16; i++&#41; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;max_c1 &#60; c1&#91;i&#93;&#41; {max_c1 = c1&#91;i&#93;; imax_c1=i;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;min_c1 &#62; c1&#91;i&#93;&#41; {min_c1 = c1&#91;i&#93;; imin_c1=i;}
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;max_c2 &#60; c2&#91;i&#93;&#41; {max_c2 = c2&#91;i&#93;; imax_c2=i;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;min_c2 &#62; c2&#91;i&#93;&#41; {min_c2 = c2&#91;i&#93;; imin_c2=i;}
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// calculate shift values as f&#40;max-min&#41;
#if PATCH
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range = max_c1 - min_c1;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// window range from 11 bit max min values
#else
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range = &#40;max_c1&#62;&#62;1&#41; - &#40;min_c1&#62;&#62;1&#41;;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// window range from 11 bit max min values
#endif
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;range &#60; 128&#41; shift_c1=0;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// for first color
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else if &#40;range &#60; 256&#41; shift_c1=1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if &#40;range &#60; 512&#41; shift_c1=2;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else if &#40;range &#60; 1024&#41; shift_c1=3;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else shift_c1=4;
#if PATCH
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range = max_c2 - min_c2;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// window range from 11 bit max min values
#else
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;range = &#40;max_c2&#62;&#62;1&#41; - &#40;min_c2&#62;&#62;1&#41;;
#endif
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;range &#60; 128&#41; shift_c2=0;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// and for second color too
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else if &#40;range &#60; 256&#41; shift_c2=1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else if &#40;range &#60; 512&#41; shift_c2=2;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;else if &#40;range &#60; 1024&#41; shift_c2=3;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else shift_c2=4;
 
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// calculate remaining 7 bit values
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;for &#40;i=0; i&#60;16; i++&#41; {
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;&#40;i&#33;= imax_c1&#41; &amp;&amp; &#40;i&#33;= imin_c1&#41;&#41; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// for first color
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;i&#93; = &#40;c1&#91;i&#93;-min_c1&#41; &#62;&#62; shift_c1;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
//#if PATCH
//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;imin_c1&#93; = c1&#91;imin_c1&#93; - min_c1;
//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c1&#91;imax_c1&#93; = c1&#91;imax_c1&#93; - min_c1;
//#endif
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;if &#40;&#40;i&#33;= imax_c2&#41; &amp;&amp; &#40;i&#33;= imin_c2&#41;&#41; {&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;// and for second color too
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;i&#93; = &#40;c2&#91;i&#93;-min_c2&#41; &#62;&#62; shift_c2;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
//#if PATCH
//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;imin_c2&#93; = c2&#91;imin_c2&#93; - min_c2;
//&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;c2&#91;imax_c2&#93; = c2&#91;imax_c2&#93; - min_c2;
//#endif
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;}
 
&#91;&#46;&#46;&#46;&#93;
 


Verbesserungsideen für weiterentwickelte Kompressionsalgorithmen in der Zukunft:

- Der bekannte Dekompressionsalgorithmus läßt es zu, daß Werte unter bestimmten Bedingungen nach oben aus dem Fenster ragen. Dies könnte kompressionsseitig bewußt ausgenutzt werden, um den Beschnitt zu reduzieren. (Ob die Kamera sowas auch macht, ist natürlich die Frage, wenn nicht, ist's eine rein akademische Fragestellung - oder eine Anregung, wie Sony mehr rausholen könnte...)

- Der Algorithmus könnte den gepackten Minimum-Wert für das Fenster so variieren, daß die Fehler innerhalb eines Pakets minimiert werden.

- Eingangseitig könnte man die Daten skalieren (durch Multiplikation mit einem Faktor oder ein Array, über das eine Kurve definiert wird), um die zur Verfügung stehende Bitbreite maximal auszunutzen.

- Anwendung von Dithering.

Viele Grüße,

Matthias


"All the important human advances that we know of since historical times began
have been due to individuals of whom the majority faced virulent public opposition."
--Bertrand Russell

http://www.mi-fo.de/forum/viewtopic.php?t=13448 (Minolta Forum Thread Index)


matthiaspaul  
matthiaspaul
Beiträge: 14.595
Registriert am: 08.06.2004


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#29 von weberhj , 27.01.2013 21:36

Hallo Matthias,

ZITAT(matthiaspaul @ 2013-01-27, 17:02) Bei mir ist das nur ein Zeitproblem, kein Interessensproblem.[/quote]
da haben wir ein gemeinsames Problem...
deshalb kann ich auch nur schnell Antworten.
ZITAT(matthiaspaul @ 2013-01-27, 17:02) Ich habe es gerade nochmal versucht, aber die obige ZIP-Datei enthält eine JPG-Datei. Dem Counter 2 nach zu urteilen hat das außer mir noch niemand runtergeladen, aber daran wären wohl sonst einige Interessenten gescheitert. Die Datei muß vor der Ausführung in .EXE umgenannt werden.[/quote]
sorry das tut mir Leid, aber ich hatte die .EXE zuvor umbenannt und versucht die .JPG hochzuladen, aber auch das hatte die Forensoftware abgelehnt, da sie wohl, ja auch richtigerweise, keine gültige .JPG Datei erkannt hat. Ich habe dann wohl aufgrund deines Tipps mit der ZIP leider fälschlicherweise die .JPG gezippt und hochgeladen. Natürlich kann man, wie du sagtest die aus dem ZIP-Archiv extrahierte .JPG einfach in .EXE umbenennen.

ZITAT(matthiaspaul @ 2013-01-27, 17:02) An Deinem Algorithmus sind mir verschiedene Dinge aufgefallen, die noch nicht ganz "wasserdicht" sind:

- Mit 15- oder 16-bittigen Eingangsdaten würde der Algorithmus nicht arbeiten.
...[/quote]
Deshalb beendet die Prozedur ja auch gleich zu Beginn, wenn nicht eine der beiden unterstützten Bittiefen von 12 und 14 vorliegen.
Meines Wissens arbeiten nahezu alle derzeitigen DSLRs mit einer Bittiefe von 12 oder 14.

1
2
3
4
 
#if PATCH
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imin_c1 = imin_c2 = 0;
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;imax_c1 = imax_c2 = 1;
#endi
 


Für imax tritt das Problem nicht auf, aber für den Fall, dass alle Werte von 16 aufeinanderfolgenden horizontalen Pixel einer Farbe tatsächlich den Wert 0 haben muss man in der Tat die imin_c1 und imin_c2 Werte mit 0 initialisieren, das werde ich einbauen. Bei der A900 kommt das in den Daten aber aufgrund des Rauschens selbst bei völlig schwarzen Aufnahmen nicht vor.

Den restlichen Punkten werde ich mich vermutlich erst am nächsten WoE annehmen können.

Schönen Abend noch

Hans


In the mind of Minolta...


weberhj  
weberhj
Beiträge: 1.117
Registriert am: 30.03.2006


RE: SLT-A99V: 14-Bit-Aufnahmen nur bei Einzelaufnahmen

#30 von Neonsquare , 27.01.2013 23:03

Auch wenn es nichts produktiv beiträgt: Bei mir ist es auch ein reines Zeitproblem - sorry. Das Thema finde ich hochinteressant und ich hoffe bald wieder darauf zurückkommen zu können.

Gruß,
[neon]


Neonsquare  
Neonsquare
Beiträge: 358
Registriert am: 05.03.2010


   

Firmware-Verbesserungswünsche für die Sony SLT-A99
Hasselblad stellt Sony SLT-A99V-Klon vor: HV

  • Ähnliche Themen
    Antworten
    Zugriffe
    Letzter Beitrag
| 2002- © so-fo.de | minolta-forum.de |
Xobor Einfach ein eigenes Forum erstellen
Datenschutz