CHDK Forum
Using CHDK => RAW Shooting and Processing => Topic started by: Treetop on 25 / May / 2008, 19:42:20
-
How can the bit depth of a raw file be found? For example, does the SD850 have 10 or 12 bit (or more, unlikely) colour depth? Maybe one of the RAW converters also shows file structure information.
Andy
-
If you read "C", Dave Coffin has his entire "C" source code right on his home page for DCRAW (can open just about any commercial RAW camera file out there--including CHDK's):
Decoding raw digital photos in Linux (http://www.cybercom.net/~dcoffin/dcraw/)
C source:
http://www.cybercom.net/~dcoffin/dcraw/dcraw.c
From what I have read, the Canon P&S cameras have an effective depth of 10bits because of limitations in the A to D converters in the small sensors. And a good dSLR is around 12 to 13 (maybe 14) bits?
-Bill
PS: Here is a short interview of Dave Coffin about his history with DCRAW (note--don't layoff software developers--it gives them too much free time :o ). :D
-
Thanks Bill; I'll have a look in the code. There is probably some location where I can find and print the largest and smallest pixel values found.
I had looked at the raw file itself but that didn't show clear patterns.
Andy
-
Forgot the link to the Dave Coffin interview:
RAW storm in a teacup? Dave Coffin interviewed: Digital Photography Review (http://www.dpreview.com/news/0504/05042701davecoffininterview.asp)
-Bill
-
what about the G9 RAW, is it 10 or 12bit ?
-
At least, in some PowerShot cameras Canon uses 12-bit ADC, but 2 lowest data bits are unconnected.
-
Where did you find this circuit diagram?? Did you break in Canon's?! :D
-
@user1: if you got more informations about the cameras, you could help a lot :)
-
User1 - would your info show what kind of USB interface is used on the camera? It's low probability, but there might be a way to toggle the USB data lines and therefore use that as a signal output from the camera. I can look through the data sheets (if it's a commercial part) to see if that might work.
Doing this would probably make the USB non-functional until the next power cycle which would be an OK drawback, but this would allow the MD script to trigger another camera (a DSLR) for instance.
-
hmm.. i don't think its possible to know something about how the chdk crw is written by looking at dcraw.c... impossible (for me). I want to know, how are crw files written? in what format?
-
In this format (http://www.sno.phy.queensu.ca/~phil/exiftool/canon_raw.html).
That's not CHDK's raws, though, that's actual CRWs. The former are merely a verbatim copy of the bits from the sensor (at least before bad pixels removal and raw frame subtracting takes place).
-
so, if im going to read it in C, should i block them as 10-bits? 12 bits or 16-bits?
-
so, if im going to read it in C, should i block them as 10-bits? 12 bits or 16-bits?
as 10 bits.
The sensor matrix is:
R G R G R G
G B G B G B
R G R G R G
G B G B G B
And the raw data buffer:
R(0,0)G(0,1)R(0,2)G(0,3)...G(0,c-1)G(1,0)B(1,1)G(1,2)B(1,3)...B(1,c-1)R(2,0),G(2,1),R(2,2)...B(r-1,c-1)
with all values 10bits
And CHDK's CRW only contains this sensor data, no other information, so its size is eg for a 7MP camera exactly 3152*2340*10/8=9219600 bytes (resolution is cropped to 3072*2304 during JPEG conversion).
Some useful code from dcraw:
// returns color of pixel
const int pattern = 0x94949494;
inline int FC(unsigned int row, unsigned int col)
{
return (pattern >> ((((row) << 1 & 14) + ((col) & 1)) << 1) & 3);
}
inline unsigned short swap_bytes_uint16(unsigned short src)
{
unsigned char upper = ((src & 0xff00) >> 8);
unsigned char lower = (src & 0x00ff);
return ((lower << 8) | upper);
}
unsigned char data_bytes[number_of_bytes];
unsigned short data_pixs[number_of_pixels];
const unsigned short* dp = data_bytes;
for(j = 0; j < number_of_pixels; j++)
{
#if qDNGBigEndian // target platform endianness (0 for intel/x86, 1 for macos, ?? for arm)
if (vbits < 10) buf = (vbits += 16, (buf << 16) + swap_bytes_uint16(*dp++));
#else
if (vbits < 10) buf = (vbits += 16, (buf << 16) + *dp++);
#endif
data_pixs[j] = buf >> (vbits -= 10) & 0x3ff;
}
-
from what i understand, chdk still writes it as 10-bit. like this
11 0101 1010 11 1011 1100
but if im going to read it, i will see:
1101 0110 1011 1011 1100
so i still have to divide/block it as 10 bit. am i right?
-
Yes.
-
now i got a new problem. it seems (to me) that crw is written in utf-16. is it possible to convert it to integer values?
-
now i got a new problem. it seems (to me) that crw is written in utf-16. is it possible to convert it to integer values?
utf-16 is a character encoding for text files, crw files are binary files, there is no character encoding involved. The 10 bits integers are written one after the other in the file. The code from dcraw I posted works fine to read the 10 bits values from the file...
-
ok. i think im really reading the file wrong. i'll study again.
-
thanks for your help. i just want to clarify, for example i get this series of bits:
ABCD EFGH IJKL MNOP QRST
since its little-endian, should i read the first two 10-bit as:
JI HGFE DCBA and TS RQPO NMLK ?
or is it like this:
IJ EFGH ABCD and ST OPQR KLMN ?
sorry for the trouble, this is my first time doing stuffs like this.
-
I'm not really in my right mind to answer right now, but why don't you look at the raw_merge.c code? This stuff answers you if you know how to read it (and I normally know but not now):
row[i+0]+=((0x3fc&(((unsigned short)rawrow[src+1])<<2)) | (rawrow[src+0] >> 6));
row[i+1]+=((0x3f0&(((unsigned short)rawrow[src+0])<<4)) | (rawrow[src+3] >> 4));
row[i+2]+=((0x3c0&(((unsigned short)rawrow[src+3])<<6)) | (rawrow[src+2] >> 2));
row[i+3]+=((0x300&(((unsigned short)rawrow[src+2])<<8)) | (rawrow[src+5]));
row[i+4]+=((0x3fc&(((unsigned short)rawrow[src+4])<<2)) | (rawrow[src+7] >> 6));
row[i+5]+=((0x3f0&(((unsigned short)rawrow[src+7])<<4)) | (rawrow[src+6] >> 4));
row[i+6]+=((0x3c0&(((unsigned short)rawrow[src+6])<<6)) | (rawrow[src+9] >> 2));
row[i+7]+=((0x300&(((unsigned short)rawrow[src+9])<<8)) | (rawrow[src+8]));
-
yey. i did it. the secret is really in that line of codes. should have figured it out earlier if i looked into it harder.
thanks for the help.
-
The sensor matrix is:
R G R G R G
G B G B G B
R G R G R G
G B G B G B
And the raw data buffer:
R(0,0)G(0,1)R(0,2)G(0,3)...G(0,c-1)G(1,0)B(1,1)G(1,2)B(1,3)...B(1,c-1)R(2,0),G(2,1),R(2,2)...B(r-1,c-1)
with all values 10bits
Hi, thanks for the valuable information!
I want to apply a smoothing filter on the CHDK's RAW file, but the results went wrong somehow.
So I tested a little bit: by setting each 10-bit value to its maximum (1023) and use dng4ps2 to create a DNG file.
It's the sensor matrix I got:
B G B G B G
G B G B G B
For example, assigning 1023 0 1023 0 1023 0 ... (each 10-bit long) on each EVEN row would give me a blue image.
Assigning 0 1023 0 1023 0 1023 ... on each EVEN row would give me a green image.
Assigning 1023 0 1023 0 1023 0 ... on each ODD row would give me a green image.
And last, assigning 0 1023 0 1023 0 1023 ...on each ODD row would give me a blue image.
It's quite strange. (since I didn't see any RED image)
I've tested for hours but didn't know why.
My code is modified from trunk's raw_merge.c, so I was assuming the process didn't go wrong.
If anyone knows what's my problem, please tell me.
Any help is appreciated! :(
PS. Assigning all zeros to a CHDK RAW file and convert to DNG. The result is a black image.
However, by setting the first 10-bit sensor data to maximum (1023) with all others 0, the result becomes a GREEN image.
I think it should be a black image with a green point inside, while it is not. @@
-
The sensor matrix is:
R G R G R G
G B G B G B
R G R G R G
G B G B G B
This is what I tried to implement: (take the first row for example)
Note that the RAW data collects (R)ed (G)reen (R)ed (G)reen ... at the first row.
Let the values be R1 G1 R2 G2 R3 G3 ..., etc.
My attempt is to set R2 = (R1 / 4) + (R2 / 2) + (R3 / 4) and G2 = (G1 / 4) + (G2 / 2) + (G3 / 4), and so on.
I was thinking that would smooth the whole image since the sharper pixel would be averaged out. (I guess)
Don't know if it is correct or not.
Thanks
-
Hi,
This is my source code: (I think it's readable)
http://oz.nthu.edu.tw/~d924324/c.c
Also I have a CHDK RAW here for testing (CRW_2211.CR2): zSHARE - crw_2211.cr2 (http://www.zshare.net/download/181734145b2cb26e/)
Of course you can switch to any RAW file by modifying one line of the C code.
This will generate another RAW file named CRW_OUT.CR2, which can be transformed to DNG by dng4ps2.
The code is to implement a simple smooth filter in the image.
For a fixed row (having values R1 G1 R2 G2 R3 G3 ...), R2 is set to be (R1 / 4) + (R2 / 2) + (R3 / 4) and so on.
The output file is generated in such a way.
However, the output file (CRW_OUT.CR2) has some noise which the original RAW does't have.
If anyone is able to check this out and know what's the problem, please tell me. :)
Thanks a lot.
-
Hi,
The code is to implement a simple smooth filter in the image.
For a fixed row (having values R1 G1 R2 G2 R3 G3 ...), R2 is set to be (R1 / 4) + (R2 / 2) + (R3 / 4) and so on.
The output file is generated in such a way.
Here is some code that I wrote to average odd with odd and even with even in each row. It seemed to work, but I realized that Canon does a better job of smoothing. Just choose an ISO of 400 or 800 when you develop the raws and Canon will apply smoothing for you.
//average odd with odd and even with even in each row
void raw_ave() {
short i,j;
unsigned short pixVal0, pixVal1, pixVal2, pixVal3;
unsigned char *src;
// Set pointer to picture raw data in memory
src = (unsigned char *) hook_raw_image_addr();
// Loop through picture rows
for (i=CAM_RAW_ROWS; i;i-=2){
// Loop through picture columns
for (j=CAM_RAW_ROWPIX; j; j-=8, src+=10){
pixVal0= ((0x3fc&(((unsigned short)(*(src+1)))<<2)) | (*(src+0) >> 6));
pixVal1= ((0x3f0&(((unsigned short)(*(src+0)))<<4)) | (*(src+3) >> 4));
pixVal2= ((0x3c0&(((unsigned short)(*(src+3)))<<6)) | (*(src+2) >> 2));
pixVal3= ((0x300&(((unsigned short)(*(src+2)))<<8)) | (*(src+5)));
pixVal0 = (pixVal0 + pixVal2)/2;
pixVal2 = pixVal0;
pixVal1 = (pixVal1 + pixVal3)/2;
pixVal3 = pixVal1;
*(src+1) = (unsigned char) ((pixVal0>>2)); // 0
*(src+0) = (unsigned char) ((pixVal0<<6)|(pixVal1>>4)); //0, 1
*(src+3) = (unsigned char) ((pixVal1<<4)|(pixVal2>>6)); //1,2
*(src+2) = (unsigned char) ((pixVal2<<2)|(pixVal3>>8)); //2,3 =>(2,0)
*(src+5) = (unsigned char) ((pixVal3)); //3 (=>0)
pixVal0=((0x3fc&(((unsigned short)(*(src+4)))<<2)) | (*(src+7) >> 6));
pixVal1=((0x3f0&(((unsigned short)(*(src+7)))<<4)) | (*(src+6) >> 4));
pixVal2=((0x3c0&(((unsigned short)(*(src+6)))<<6)) | (*(src+9) >> 2));
pixVal3=((0x300&(((unsigned short)(*(src+9)))<<8)) | (*(src+8)));
pixVal0 = (pixVal0 + pixVal2)/2;
pixVal2 = pixVal0;
pixVal1 = (pixVal1 + pixVal3)/2;
pixVal3 = pixVal1;
*(src+4) = (unsigned char) ((pixVal0>>2)); // 4 => 0
*(src+7) = (unsigned char) ((pixVal0<<6)|(pixVal1>>4)); // 4,5 => (0,1)
*(src+6) = (unsigned char) ((pixVal1<<4)|(pixVal2>>6)); // 5,6 => (1,2)
*(src+9) = (unsigned char) ((pixVal2<<2)|(pixVal3>>8)); // 6,7 =>(2,0)
*(src+8) = (unsigned char) ((pixVal3)); //7 (=>0)
}
for (j=CAM_RAW_ROWPIX; j; j-=8, src+=10){
pixVal0=((0x3fc&(((unsigned short)(*(src+1)))<<2)) | (*(src+0) >> 6));
pixVal1=((0x3f0&(((unsigned short)(*(src+0)))<<4)) | (*(src+3) >> 4));
pixVal2=((0x3c0&(((unsigned short)(*(src+3)))<<6)) | (*(src+2) >> 2));
pixVal3=((0x300&(((unsigned short)(*(src+2)))<<8)) | (*(src+5)));
pixVal0 = (pixVal0 + pixVal2)/2;
pixVal2 = pixVal0;
pixVal1 = (pixVal1 + pixVal3)/2;
pixVal3 = pixVal1;
*(src+1) = (unsigned char) ((pixVal0>>2)); // 0
*(src+0) = (unsigned char) ((pixVal0<<6)|(pixVal1>>4)); //0, 1
*(src+3) = (unsigned char) ((pixVal1<<4)|(pixVal2>>6)); //1,2
*(src+2) = (unsigned char) ((pixVal2<<2)|(pixVal3>>8)); //2,3 =>(2,0)
*(src+5) = (unsigned char) ((pixVal3)); //3 (=>0)
pixVal0=((0x3fc&(((unsigned short)(*(src+4)))<<2)) | (*(src+7) >> 6));
pixVal1=((0x3f0&(((unsigned short)(*(src+7)))<<4)) | (*(src+6) >> 4));
pixVal2=((0x3c0&(((unsigned short)(*(src+6)))<<6)) | (*(src+9) >> 2));
pixVal3=((0x300&(((unsigned short)(*(src+9)))<<8)) | (*(src+8)));
pixVal0 = (pixVal0 + pixVal2)/2;
pixVal2 = pixVal0;
pixVal1 = (pixVal1 + pixVal3)/2;
pixVal3 = pixVal1;
*(src+4) = (unsigned char) ((pixVal0>>2)); // 4 => 0
*(src+7) = (unsigned char) ((pixVal0<<6)|(pixVal1>>4)); // 4,5 => (0,1)
*(src+6) = (unsigned char) ((pixVal1<<4)|(pixVal2>>6)); // 5,6 => (1,2)
*(src+9) = (unsigned char) ((pixVal2<<2)|(pixVal3>>8)); // 6,7 =>(2,0)
*(src+8) = (unsigned char) ((pixVal3)); //7 (=>0)
}
}
}
-
Thank you, Jon! :D
I'll study your code carefully.
I'm doing this for the mimic of 'portrait enhancer mode' of Fujifilm's DC.
So I would like to apply some "heavier" smoothing filter in camera's memory before it is saved in our SD card.
Thanks again! :xmas
-
Here is some code that I wrote to average odd with odd and even with even in each row. It seemed to work, but I realized that Canon does a better job of smoothing. Just choose an ISO of 400 or 800 when you develop the raws and Canon will apply smoothing for you.
Dear Jon,
I've read your code and compared to mine, it seems that our programs do almost the same thing.
So I put your raw_ave() function in the firmware and test two shots.
One does average-filter (according your code) and the other one does not.
The attachments are the two results (100% crop from the JPEG in camera, no postprocessing).
The one which is applied filter still contains noise and the noise is too sharp to be ignored.
I really cannot find any reason for that, I think I would give up if no one knows why :(
Still thank you for your help!
Best Regards,
John
-
littlejohn, This is not a noise. Dark points are bad bixels which should be removed before demosaic process
-
littlejohn, This is not a noise. Dark points are bad bixels which should be removed before demosaic process
Dear ArtDen,
Thanks for the information. :D
Could you give me some hints about how to remove those bad pixels?
Since all I tried to do is to assign the average value between each neighboring R/G/B,
I don't know what I can do to prevent those dark points from happening.
And I have no idea how that came out.
Thanks,
John
-
Hi John,
Those are too many points to be bad pixels. I seems a random pattern of errors introduced by the processing. I don't get such points on my camera, a 720is. Perhaps some other task is interfering with the read or write of the pixel data.
Jon
I've read your code and compared to mine, it seems that our programs do almost the same thing.
So I put your raw_ave() function in the firmware and test two shots.
One does average-filter (according your code) and the other one does not.
The attachments are the two results (100% crop from the JPEG in camera, no postprocessing).
The one which is applied filter still contains noise and the noise is too sharp to be ignored.
I really cannot find any reason for that, I think I would give up if no one knows why :(
Still thank you for your help!
Best Regards,
John
-
Hi John,
Those are too many points to be bad pixels. I seems a random pattern of errors introduced by the processing. I don't get such points on my camera, a 720is. Perhaps some other task is interfering with the read or write of the pixel data.
Jon
Hi Jon :)
Good to see your reply. :D
Yes, the bad pixels are likely to be introduced by processing error.
However, I don't think it's camera dependent problem.
I have inserted your code in my firmware build. (Ixus860)
Also, I myself implemented another version (which I posted lately) in Linux, which reads a CR2 file and generate another one.
My program only reads a CR2 file, retrieves the RGB values, and set the modified values back.
In both cases, the bad pixels remain there.
(In the first case, bad pixels were shown directly on the camera's LCD.
In the second case, bad pixels were shown in the DNG file produced by dng4ps.)
Now I'm thinking of the correctness of the implementation.
If I set all values representing "G" (Green) to its maximum (1023), it is green.
If I set those values to 512, it turns to pink.
Maybe calculating the average has some flaw.
I'll have some more tests in my free time.
Regards,
John
-
Could you give me some hints about how to remove those bad pixels?
Since all I tried to do is to assign the average value between each neighboring R/G/B,
Yes, this is simpliest and good way to remove bad pixels. You can look how dcraw software does it:
http://www.cybercom.net/~dcoffin/dcraw/dcraw.c ('remove_zeroes' method)
-
Hi All,
I'm trying to load CRW files from an SD-1000 in MATLAB, but when I do so they don't look right. I expect them to look approximately like a grayscale version of the image I shot. However, I end up with a lot of vertical lines. I can see the major image elements, but there's clearly something wrong here. I've posted my code below.
Can anyone answer the following?
1. Is the SD-1000 RAW output definitely 10-bit?
2. Is the data big endian or little?
3. Can anyone look at my code and tell me if they can spot the problem?
% SD-1000 sensor resolution
h=2340;
w=3152;
% Name of file to read
filename='CRW_3160.CRW';
fid=fopen(filename,'r','b');
% Read 10-bit Uint data into columns of height w, then transpose the matrix
rawimg = fread(fid,[w Inf],'ubit10=>double')';
fclose(fid);
% Linearly compress 10-bit data into [0 1] double range
% This should look roughly like a grayscale picture of the scene, which it
% doesn't.
imshow(rawimg/max(rawimg(:)));
-
http://chdk.wikia.com/wiki/Frame_buffers#Raw (http://chdk.wikia.com/wiki/Frame_buffers#Raw) may be helpful. You are probably getting tripped up by the packed little endian format. The SD1000 is definitely 10bpp. The important specs may be found in http://tools.assembla.com/chdk/browser/trunk/platform/ixus70_sd1000/platform_camera.h (http://tools.assembla.com/chdk/browser/trunk/platform/ixus70_sd1000/platform_camera.h)
You can also get C code to read the from http://tools.assembla.com/chdk/browser/trunk/tools/rawconvert.c (http://tools.assembla.com/chdk/browser/trunk/tools/rawconvert.c)
You could use rawconvert to convert it into a format that is easier to read in matlab, e.g. 16 bit
-
@reyalp: Thanks for the reply. The bit packing order is definitely what's messing me up. Is there a Windows binary of rawconvert? I tried compiling the c file but I'm missing some of the dependancies and it looks like they're hard to get working in Windows.
-
@reyalp: Thanks for the reply. The bit packing order is definitely what's messing me up. Is there a Windows binary of rawconvert? I tried compiling the c file but I'm missing some of the dependancies and it looks like they're hard to get working in Windows.
I think rawconvert is quite vanilla C, not sure why you couldn't just use <compiler> rawconvert.c but here's a binary
-
@reyalp: The problem I was running into was that I was missing stdint.h and platform.h. Apparently Microsoft removed these from their standard libraries included with Visual Studio 2008. They've reinstated them in 2010. There's a lot of discussion about this online. I've since been able to compile it myself.
Now I have a question about the usage. I've got a raw file from an SD-1000, so it's 10bpp with the unusual bit-packing order. I use rawconvert to convert it to 16bpp with the following command:
rawconvert.exe -10to16 -w=3152 -h=2340 -pgm CRW_3133.CRW CRW_3133_16.CRW
The pgm looks correct, i.e. it looks like grayscale Bayer mosaiced data. Now I'd expect to be able to load this in MATLAB as 16bpp data and basically see the same thing. I do this as follows:
filename='CRW_3133_16.CRW';
bpp=16;
fid=fopen(filename, 'r', 'l')
P=fgetl(fid);
w=str2double(fgetl(fid));
h=str2double(fgetl(fid));
maxval=str2double(fgetl(fid));
temp=fread(fid, [h Inf], ['ubit' num2str(bpp)]);
size(temp)
fclose(fid);
min(temp(:))
max(temp(:))
imshow(temp/max(temp(:)),[]);
However, it does not appear to load the data correctly, it's just random looking noise. Is the bit-packing still in an unusual setup? I assumed that in 16bpp it would just be normal uint16.
Can you offer any further advice? Thanks for your help so far.
-
FWIW, if you do rawconvert without PGM, the file will simply be 16 bit ints in native byte order. (which in practice must be little endian...)
PGM appears to reverse the byte order for 16 bit. According to wikipedia:
The original definition of the PGM and the PPM binary formats (the P5 and P6 formats) did not allow bit depths greater than 8 bits. One can of course use the ASCII format, but this format both slows down reading and makes the files much larger. Accordingly, many programmers have attempted to extend the format to allow higher bit depths. Using higher bit depths encounters the problem of having to decide on the endianness of the file. Unfortunately it appears that the various implementations could not agree on which byte order to use, and some connected the 16-bit endianness to the pixel packing order.[3] In Netpbm, the de facto standard implementation of the PNM formats, the most significant byte is first.