Bit depth of raw files?

LjL

266
A720IS

Re: Bit depth of raw files?

« Reply #10 on: 27 / July / 2008, 15:30:39 »

Advertisements

In this format.

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).

Logged

octagonx

15

Re: Bit depth of raw files?

« Reply #11 on: 28 / July / 2008, 05:31:59 »

so, if im going to read it in C, should i block them as 10-bits? 12 bits or 16-bits?

Logged

cyril42e

111
SD1000/Ixus70 1.02a

Re: Bit depth of raw files?

« Reply #12 on: 28 / July / 2008, 05:43:23 »

Quote from: octagonx on 28 / July / 2008, 05:31:59

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:

Code: [Select]

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:

Code: [Select]

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:

Code: (c) [Select]

// 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;
	}

« Last Edit: 28 / July / 2008, 05:55:34 by cyril42e »

Logged

octagonx

15

Re: Bit depth of raw files?

« Reply #13 on: 28 / July / 2008, 08:21:38 »

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?

Logged

LjL

266
A720IS

Re: Bit depth of raw files?

« Reply #14 on: 28 / July / 2008, 08:24:48 »

Yes.

Logged

octagonx

15

Re: Bit depth of raw files?

« Reply #15 on: 28 / July / 2008, 11:15:15 »

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?

Logged

cyril42e

111
SD1000/Ixus70 1.02a

Re: Bit depth of raw files?

« Reply #16 on: 28 / July / 2008, 11:21:52 »

Quote from: octagonx on 28 / July / 2008, 11:15:15

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...

Logged

octagonx

15

Re: Bit depth of raw files?

« Reply #17 on: 28 / July / 2008, 11:39:14 »

ok. i think im really reading the file wrong. i'll study again.

Logged

octagonx

15

Re: Bit depth of raw files?

« Reply #18 on: 28 / July / 2008, 13:53:52 »

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.

Logged

LjL

266
A720IS

Re: Bit depth of raw files?

« Reply #19 on: 28 / July / 2008, 14:16:47 »

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):

Code: [Select]

           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]));

Logged