throwcomputer
Posts: 11
Joined: Thu May 16, 2013 6:30 am

Re: RAW output information

Wed May 29, 2013 12:08 am

I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
jbeale wrote:
jamesh wrote:...this stuff doesn't happen overnight. That said, I'm sure someone will spend the time on it.
Yes, and probably... finding out small bits at a time. Earlier I had assumed the Bayer filter on the sensor was R-G-G-B, but at the moment it seems closer to C-Y-Y-M (cyan, yellow x2, magenta) ...or maybe it's just a clipping effect. It will be a while before I can do some better color charts, and make an effort on the Raw->XYZ->RGB color transform. Presumably the tuning experts did all this already, but I don't know if their reference illuminant, color matrix etc. is public knowledge?

As people have been noticing, the all-round image quality as it stands is really quite good, and at this point I don't see any big improvements likely. Changing the tone curve after the fact may improve some highlights, but of course this sensor has 10-bit output, not 12 or 14 bits like DSLRs. In contrast-stretching very low light images, I see some fixed-pattern noise (vertical streaks) as well as random noise. One thing RAW may enable is a more consistent reference for black frame subtraction and flat-fielding, if you want to squeeze that last % of sensor performance.

AlanD
Posts: 4
Joined: Wed May 29, 2013 6:27 am

Re: RAW output information

Wed May 29, 2013 6:35 am

throwcomputer wrote:I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
Just for reference: an issue has been filed against RaspiStill.c.

kaos
Posts: 108
Joined: Mon Mar 26, 2012 8:14 pm

Re: RAW output information

Wed May 29, 2013 8:51 am

throwcomputer wrote:I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
I don't think 24fps of raw data can be achieved. As I understand it, raw data is always full sensor resolution, regardless of the jpg resolution, so that's about 6.1 Mbyte * 24 fps = ca. 147 Mbytes/second, while the fastest class 10 SD cards can only guarantee 10 Mbytes/second, and I seem to recall that the Raspi cannot even keep up with that.

--
Regards, Kári.

AlanD
Posts: 4
Joined: Wed May 29, 2013 6:27 am

Re: RAW output information

Wed May 29, 2013 12:03 pm

jbeale wrote:
jamesh wrote:...this stuff doesn't happen overnight. That said, I'm sure someone will spend the time on it.
Yes, and probably... finding out small bits at a time. Earlier I had assumed the Bayer filter on the sensor was R-G-G-B, but at the moment it seems closer to C-Y-Y-M (cyan, yellow x2, magenta) ...or maybe it's just a clipping effect. It will be a while before I can do some better color charts, and make an effort on the Raw->XYZ->RGB color transform. Presumably the tuning experts did all this already, but I don't know if their reference illuminant, color matrix etc. is public knowledge?
Patching your code to emit a color PPM assuming the sensor is BGGR gives
raw-full-330pm.BGGR.jpg
raw-full-330pm.BGGR.jpg (57.58 KiB) Viewed 10415 times
after minor manipulation (gamma correction, manual white balance and saturation):

Code: Select all

... | convert - -resize 50% -color-matrix "$(echo -e '6 0 0\n0 2 0\n0 0 4')" -gamma 10 -modulate 100,120 -normalize output.jpg
The lack of sharpening, vignetting compensation, etc become visible when looking at the difference of the GPU generated JPEG and the previous rawish result:
difference.jpg
difference.jpg (61.47 KiB) Viewed 10415 times

The patch to emit a color PPM according to the BGGR layout:

Code: Select all

--- raspiraw.c.ori	2013-05-29 10:27:21.705046072 +0200
+++ raspiraw.c	2013-05-29 13:58:50.867292274 +0200
@@ -29,6 +29,7 @@ unsigned long offset;  // offset into fi
 unsigned char *buffer;
 unsigned short pixel[HPIXELS];  // array holds 16 bits per pixel
 unsigned char split;        // single byte with 4 pairs of low-order bits
+int r,g,b;
 
 
 strcpy(fname,"raw-full-330pm.jpg");
@@ -81,7 +82,7 @@ if (fp==NULL)  {
 
 //  printf("%x %x %x %x %x\n",buffer[0], buffer[1], buffer[2], buffer[3], buffer[4]);
 
-  printf("P2\n%d %d\n65535\n",HPIXELS,VPIXELS);  // ASCII PGM format header  (grey bitmap, 16 bits per pixel)
+  printf("P3\n%d %d\n65535\n",HPIXELS,VPIXELS);  // ASCII PGM format header  (grey bitmap, 16 bits per pixel)
  
   for (k=0; k < VPIXELS; k++) {  // iterate over pixel rows
     fread(buffer, ROWSIZE, 1, fp);  // read next line of pixel data
@@ -98,8 +99,14 @@ if (fp==NULL)  {
       pixel[i+3] += (split & 0b00000011)<<6;
     }
     for (i = 0; i < HPIXELS; i++) {
+      r = 0; g = 0; b = 0;
+      if (i % 2 == 0 && k % 2 == 0) { b = pixel[i]; }
+      else if (i % 2 == 1 && k % 2 == 1) { r = pixel[i]; }
+      else { g = pixel[i]; }
       //printf("%d ",pixel[i]>>8);
-      printf("%d ",pixel[i]);
+      printf("%d ",r); // R
+      printf("%d ",g); // G
+      printf("%d ",b); // B
     }
     printf("\n");  // add an end-of-line char

throwcomputer
Posts: 11
Joined: Thu May 16, 2013 6:30 am

Re: RAW output information

Wed May 29, 2013 4:32 pm

Yes that was my bug report!

AlanD wrote:
throwcomputer wrote:I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
Just for reference: an issue has been filed against RaspiStill.c.

throwcomputer
Posts: 11
Joined: Thu May 16, 2013 6:30 am

Re: RAW output information

Wed May 29, 2013 4:35 pm

You are correct, but this issue goes beyond raw flags as only the first frame is recorded raw using raspistill in timelapse mode. There seems to be another bottleneck within the chain of operations as even setting up an execution without the raw flag but in timelapse mode (ie. raspistill -t 5000 -tl 41.67 -o image_%d.jpg) does not generate image sequences at the desired 41.67 milliseconds (24fps).. even with the width and height set to 320x240 to ensure there is more than enough data bandwidth for this.
kaos wrote:
throwcomputer wrote:I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
I don't think 24fps of raw data can be achieved. As I understand it, raw data is always full sensor resolution, regardless of the jpg resolution, so that's about 6.1 Mbyte * 24 fps = ca. 147 Mbytes/second, while the fastest class 10 SD cards can only guarantee 10 Mbytes/second, and I seem to recall that the Raspi cannot even keep up with that.

--
Regards, Kári.

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Wed May 29, 2013 4:45 pm

Nice work AlanD! I was just about to post my realization that the sensor was BGGR, but I see someone is there already. Looks to me like the "RAW' data is not linear light, but has some gamma applied already (perhaps not the same as the JPEG output though). Comparing the raw and JPEG versions at full res, looks like there was some de-noising in the latter as well as sharpening. Compare the crops below, first is JPEG output, second is assembled RAW planes simply interpreted as BGGR planes with sRGB colorspace. No debayer, so the JPEG was first downscaled to 50% to match sizes. This gives you some idea of what the camera tuning team has done.

ImageImage
Note: Image has low contrast due to subject outside, camera inside looking through a double-paned window.
Last edited by jbeale on Wed May 29, 2013 5:05 pm, edited 6 times in total.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23659
Joined: Sat Jul 30, 2011 7:41 pm

Re: RAW output information

Wed May 29, 2013 4:46 pm

throwcomputer wrote:You are correct, but this issue goes beyond raw flags as only the first frame is recorded raw using raspistill in timelapse mode. There seems to be another bottleneck within the chain of operations as even setting up an execution without the raw flag but in timelapse mode (ie. raspistill -t 5000 -tl 41.67 -o image_%d.jpg) does not generate image sequences at the desired 41.67 milliseconds (24fps).. even with the width and height set to 320x240 to ensure there is more than enough data bandwidth for this.
kaos wrote:
throwcomputer wrote:I've also been playing around with the raw output to jpg since receiving my camera.. but trying to get it to output timelapse with intervals close to what would equal 24fps video. Unfortunately, its immediately clear once you enable the raw flag with timelapse mode that only the first frame of the image sequence actually has raw data embedded into exif.. all following stills seem to "forget" this flag is enabled.
I don't think 24fps of raw data can be achieved. As I understand it, raw data is always full sensor resolution, regardless of the jpg resolution, so that's about 6.1 Mbyte * 24 fps = ca. 147 Mbytes/second, while the fastest class 10 SD cards can only guarantee 10 Mbytes/second, and I seem to recall that the Raspi cannot even keep up with that.

--
Regards, Kári.
Are you joking? 41.67ms is way too fast for the data to be grabbed and stuffed over to the ARM, then buffered and saved to the SD card. The sensor can only capture at 15fps in stills mode anyway (sensor limitation at full rez).

Timelapse mode is intended for picture taking much more leisurely than that.(like every 5 seconds). hence the phrase timelapse.

What's wrong with video recording if you want 24fps? You can have that at 1080p24 with 30Mbits/s bitrate. Quality will be way better than 320x240 stills.

You might be able to rewrite the app to avoid SD card access and buffer up in the ARM memory until you run out. You might get a higher frame rate then.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

philrosenberg
Posts: 4
Joined: Thu May 30, 2013 3:21 pm

Re: RAW output information

Thu May 30, 2013 3:34 pm

I'm quite interested in this too as I am looking at potential ways to use a camera for photometry so ideally would like to specify exposure time and get raw output and write some area of the frame to file as quickly as possible. I'm not sure if the Pi camera can do what i need as it is fixed focus, but it might well do.

Anyway looking at the source code for raspicam it seems like changing the fopen() calls to use fmemopen() would allow the output to sent to a buffer in memory instead of a file then you could select the apropriate region of the raw data that you actually needed and write this to file.

I'm just looking throught the code now to see if I can see how the exposure is set too. Unfortunately I don't have a camera to test with, but i might well order one now.

Phil

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Thu May 30, 2013 6:15 pm

philrosenberg wrote:...would like to specify exposure time...
You and me both! Apparently there are two parameters to control, exposure time and ISO setting. Do you think those can be set by rewriting the raspistill code? I was under the impression that the camera was always in auto-exposure mode as it stands, and we can change exposure compensation up or down relative to the "nominal" auto-exposure value, but we do not have the camera hardware documentation and/or GPU interface documentation needed to set a full manual exposure. I would love to be told I'm wrong about that.

The RPi foundation sent out 10 preproduction camera models to people about a month before the worlwide release, after a contest and judging who had the most worthy projects. I suppose those projects are still going; I'm not sure what results have been achieved so far. I think the foundation still have some kept back for engineering use, so maybe there is hope to get one if you convinced them you could contribute useful code and presented a suitably compelling project (admittedly, that would be a long shot). Otherwise, lead times are somewhat long- my local supplier, MCM Electronics says 50 days. Or pay an inflated price on ebay.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23659
Joined: Sat Jul 30, 2011 7:41 pm

Re: RAW output information

Fri May 31, 2013 7:46 am

jbeale wrote:
philrosenberg wrote:...would like to specify exposure time...
You and me both! Apparently there are two parameters to control, exposure time and ISO setting. Do you think those can be set by rewriting the raspistill code? I was under the impression that the camera was always in auto-exposure mode as it stands, and we can change exposure compensation up or down relative to the "nominal" auto-exposure value, but we do not have the camera hardware documentation and/or GPU interface documentation needed to set a full manual exposure. I would love to be told I'm wrong about that.

The RPi foundation sent out 10 preproduction camera models to people about a month before the worlwide release, after a contest and judging who had the most worthy projects. I suppose those projects are still going; I'm not sure what results have been achieved so far. I think the foundation still have some kept back for engineering use, so maybe there is hope to get one if you convinced them you could contribute useful code and presented a suitably compelling project (admittedly, that would be a long shot). Otherwise, lead times are somewhat long- my local supplier, MCM Electronics says 50 days. Or pay an inflated price on ebay.
There is a MMAL parameter to set the ISO - it's commented out in the code. Can't remember why but presumably because it didn't work!

It's on my extensive list of things to check, but time is short at the moment.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

axse
Posts: 7
Joined: Mon May 20, 2013 6:29 am

Re: RAW output information

Fri May 31, 2013 8:44 am

jbeale wrote:
philrosenberg wrote:...would like to specify exposure time...
You and me both! Apparently there are two parameters to control, exposure time and ISO setting. .
me too.

philrosenberg
Posts: 4
Joined: Thu May 30, 2013 3:21 pm

Re: RAW output information

Fri May 31, 2013 9:44 am

Just looked on RS - dispatch expected within 12 weeks. I need to be up and running in 2 weeks. I have a logitech camera that does raw output arriving next week so I may have to live with that, which is a shame, because the programming interface for the Pi camera looks pretty straightforward.

I hadn't looked in too much detail at the code for exposure, nor do I know anything about the hardware other than the sticky links on the forum, so if you say manual exposure isn't possible then I believe you.

I will order one to play with when it arrives, but in the mean time I think there's enough info in this thread now for someone with a camera to update the raspicam code to do raw timelapse, and to only save a limited field of raw data.

Phil

Phil

AlanD
Posts: 4
Joined: Wed May 29, 2013 6:27 am

Re: RAW output information

Sat Jun 01, 2013 1:32 pm

Building on the work of jbeale and Dave Coffin, I've prepared a skeleton for an RPi JPEG to Adobe DNG converter. The generated DNG contains Bayer pattern specification and RAW data (no exposure metadata, calibrated color matrix, etc.).

Code: Select all

/* Read in jpeg from Raspberry Pi camera captured using 'raspistill --raw'
   and extract raw file with 10-bit values stored left-justified at 16 bpp
   in Adobe DNG (TIFF-EP) format, convert with 'ufraw out.dng' for example

   John Beale  26 May 2013
   and others
   
   Contains code written by Dave Coffin for Berkeley Engineering and Research.

   Free for all uses.


   Requires LibTIFF 3.8.0 plus a patch, see http://www.cybercom.net/~dcoffin/dcraw/

   Compile with:
   gcc -o raspi_dng raspi_dng.c -O4 -Wall -lm -ljpeg -ltiff
   
 */



#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <sys/stat.h>
#include <time.h>
#include <math.h>
#include <tiffio.h>
#include <errno.h>


#define LINELEN 256            // how long a string we need to hold the filename
#define RAWBLOCKSIZE 6404096
#define HEADERSIZE 32768
#define ROWSIZE 3264 // number of bytes per row of pixels, including 24 'other' bytes at end
#define IDSIZE 4    // number of bytes in raw header ID string
#define HPIXELS 2592   // number of horizontal pixels on OV5647 sensor
#define VPIXELS 1944   // number of vertical pixels on OV5647 sensor

int main (int argc, char **argv)
{
	static const short CFARepeatPatternDim[] = { 2,2 };
	// this color matrix is definitely inaccurate, TODO: calibrate
	static const float cam_xyz[] = {
		// R 	G     	B
		1.000,	0.000,	0.000,	// R
		0.000,	1.000,	0.000,	// G
		0.000,	0.000,	1.000	// B
	};
	static const float neutral[] = { 1.0, 1.0, 1.0 }; // TODO calibrate
	long sub_offset=0, white=0xffff;

	int status=1, i, j, row, col;
	unsigned short curve[256];
	struct stat st;
	struct tm tm;
	char datetime[64];
	FILE *ifp;
	TIFF *tif;

	const char* fname = argv[1];
	unsigned long fileLen;  // number of bytes in file
	unsigned long offset;  // offset into file to start reading pixel data
	unsigned char *buffer;
	unsigned short pixel[HPIXELS];  // array holds 16 bits per pixel
	unsigned char split;        // single byte with 4 pairs of low-order bits

	if (argc != 3) {
		fprintf (stderr, "Usage: %s infile outfile\n"
			"Example: %s rpi.jpg output.dng\n", argv[0], argv[0]);
		return 1;
	}

	if (!(ifp = fopen (fname, "rb"))) {
		perror (argv[2]);
		return 1;
	}
	stat (fname, &st);
	gmtime_r (&st.st_mtime, &tm);
	sprintf (datetime, "%04d:%02d:%02d %02d:%02d:%02d",
	tm.tm_year+1900,tm.tm_mon+1,tm.tm_mday,tm.tm_hour,tm.tm_min,tm.tm_sec);

	//Get file length
	fseek(ifp, 0, SEEK_END);
	fileLen=ftell(ifp);
	if (fileLen < RAWBLOCKSIZE) {
		fprintf(stderr, "File %s too short to contain expected 6MB RAW data.\n", fname);
		exit(1);
	}
	offset = (fileLen - RAWBLOCKSIZE) ;  // location in file the raw header starts
	fseek(ifp, offset, SEEK_SET); 
 
	//printf("File length = %d bytes.\n",fileLen);
	//printf("offset = %d:",offset);

	//Allocate memory for one line of pixel data
	buffer=(unsigned char *)malloc(ROWSIZE+1);
	if (!buffer)
	{
		fprintf(stderr, "Memory error!");
		status = ENOMEM;
		goto fail;
	}
		
	if (!(tif = TIFFOpen (argv[2], "w"))) goto fail;

	//fprintf(stderr, "Writing TIFF header...\n");
	
	TIFFSetField (tif, TIFFTAG_SUBFILETYPE, 1);
	TIFFSetField (tif, TIFFTAG_IMAGEWIDTH, HPIXELS >> 4);
	TIFFSetField (tif, TIFFTAG_IMAGELENGTH, VPIXELS >> 4);
	TIFFSetField (tif, TIFFTAG_BITSPERSAMPLE, 8);
	TIFFSetField (tif, TIFFTAG_COMPRESSION, COMPRESSION_NONE);
	TIFFSetField (tif, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_RGB);
	TIFFSetField (tif, TIFFTAG_MAKE, "Raspberry Pi");
	TIFFSetField (tif, TIFFTAG_MODEL, "Model OV5647");
	TIFFSetField (tif, TIFFTAG_ORIENTATION, ORIENTATION_TOPLEFT);
	TIFFSetField (tif, TIFFTAG_SAMPLESPERPIXEL, 3);
	TIFFSetField (tif, TIFFTAG_PLANARCONFIG, PLANARCONFIG_CONTIG);
	TIFFSetField (tif, TIFFTAG_SOFTWARE, "raspi_dng");
	TIFFSetField (tif, TIFFTAG_DATETIME, datetime);
	TIFFSetField (tif, TIFFTAG_SUBIFD, 1, &sub_offset);
	TIFFSetField (tif, TIFFTAG_DNGVERSION, "\001\001\0\0");
	TIFFSetField (tif, TIFFTAG_DNGBACKWARDVERSION, "\001\0\0\0");
	TIFFSetField (tif, TIFFTAG_UNIQUECAMERAMODEL, "Raspberry Pi - OV5647");
	TIFFSetField (tif, TIFFTAG_COLORMATRIX1, 9, cam_xyz);
	TIFFSetField (tif, TIFFTAG_ASSHOTNEUTRAL, 3, neutral);
	TIFFSetField (tif, TIFFTAG_CALIBRATIONILLUMINANT1, 21);
	TIFFSetField (tif, TIFFTAG_ORIGINALRAWFILENAME, fname);

	// fprintf(stderr, "Writing TIFF thumbnail...\n");
	memset (pixel, 0, HPIXELS);	// all-black thumbnail 
	for (row=0; row < VPIXELS >> 4; row++)
		TIFFWriteScanline (tif, pixel, row, 0);
	TIFFWriteDirectory (tif);

	// fprintf(stderr, "Writing TIFF header for main image...\n");

	TIFFSetField (tif, TIFFTAG_SUBFILETYPE, 0);
	TIFFSetField (tif, TIFFTAG_IMAGEWIDTH, HPIXELS);
	TIFFSetField (tif, TIFFTAG_IMAGELENGTH, VPIXELS);
	TIFFSetField (tif, TIFFTAG_BITSPERSAMPLE, 16);
	TIFFSetField (tif, TIFFTAG_PHOTOMETRIC, PHOTOMETRIC_CFA);
	TIFFSetField (tif, TIFFTAG_SAMPLESPERPIXEL, 1);
	TIFFSetField (tif, TIFFTAG_PLANARCONFIG, PLANARCONFIG_CONTIG);
	TIFFSetField (tif, TIFFTAG_CFAREPEATPATTERNDIM, CFARepeatPatternDim);
	TIFFSetField (tif, TIFFTAG_CFAPATTERN, 4, "\002\001\001\0"); // 0 = Red, 1 = Green, 2 = Blue, 3 = Cyan, 4 = Magenta, 5 = Yellow, 6 = White 
	//TIFFSetField (tif, TIFFTAG_LINEARIZATIONTABLE, 256, curve);
	TIFFSetField (tif, TIFFTAG_WHITELEVEL, 1, &white);

	fprintf(stderr, "Processing RAW data...\n");
	// for one file, (TotalFileLength:11112983 - RawBlockSize:6404096) + Header:32768 = 4741655
	// The pixel data is arranged in the file in rows, with 3264 bytes per row.
	// with 3264 bytes per row x 1944 rows we have 6345216 bytes, that is the full 2592x1944 image area.
 
	//Read one line of pixel data into buffer
	fread(buffer, IDSIZE, 1, ifp);

	// now on to the pixel data
	offset = (fileLen - RAWBLOCKSIZE) + HEADERSIZE;  // location in file the raw pixel data starts
	fseek(ifp, offset, SEEK_SET);

	for (row=0; row < VPIXELS; row++) {  // iterate over pixel rows
		fread(buffer, ROWSIZE, 1, ifp);  // read next line of pixel data
		j = 0;  // offset into buffer
		for (col = 0; col < HPIXELS; col+= 4) {  // iterate over pixel columns
			pixel[col+0] = buffer[j++] << 8;
			pixel[col+1] = buffer[j++] << 8;
			pixel[col+2] = buffer[j++] << 8;
			pixel[col+3] = buffer[j++] << 8;
			split = buffer[j++];    // low-order packed bits from previous 4 pixels
			pixel[col+0] += (split & 0b11000000);  // unpack them bits, add to 16-bit values, left-justified
			pixel[col+1] += (split & 0b00110000)<<2;
			pixel[col+2] += (split & 0b00001100)<<4;
			pixel[col+3] += (split & 0b00000011)<<6;
		}
		if (TIFFWriteScanline (tif, pixel, row, 0) != 1) {
			fprintf(stderr, "Error writing TIFF scanline.");
			exit(1);
		}
	} // end for(k..)

	free(buffer); // free up that memory we allocated

	TIFFClose (tif);
	status = 0;
fail:
	fclose (ifp);
	return status;
}
Below you can find a Makefile to download the required version of LibTiff, patch it, compile it and statically link it to the above code:

Code: Select all

all: raspi_dng

tiff-3.8.2.tar.gz:
	wget -nc 'http://dl.maptools.org/dl/libtiff/tiff-3.8.2.tar.gz'

tiff-3.8.2: tiff-3.8.2.tar.gz libtiff.patch
	tar -zxvf "$<"
	cat "libtiff.patch" | patch -p0 -f

libtiff.patch:
	wget -nc 'http://www.cybercom.net/~dcoffin/dcraw/libtiff.patch'

local/lib/libtiff.a: tiff-3.8.2
	cd $< ; ./configure --prefix=$(PWD)/local
	cd $< ; make -j4
	cd $< ; make install

clean:
	rm -rf local tiff-3.8.2 *.o

raspi_dng.o: local/lib/libtiff.a raspi_dng.c
	$(CC) -c raspi_dng.c -I./local/include -o [email protected]

raspi_dng: raspi_dng.o local/lib/libtiff.a
	$(CC) raspi_dng.o local/lib/libtiff.a -ljpeg -lm -lz -o [email protected]
What it looks like in UFRaw:
rpi_dng_ufraw.jpg
rpi_dng_ufraw.jpg (56.91 KiB) Viewed 10193 times

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Sat Jun 01, 2013 6:43 pm

Hey, excellent work AlanD! I had done almost exactly that but had a completely wrong color matrix. Your simple unity matrix looks a lot better than what I had! Will take some better color chart photos soon, to assist for calibration work.

Very convenient makefile; I never even realized you could set a makefile to download, patch and compile a library as well as just compile a local code. On my system I also had to do:

Code: Select all

sudo apt-get install libjpeg-dev 
Last edited by jbeale on Sun Jun 02, 2013 2:49 pm, edited 1 time in total.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23659
Joined: Sat Jul 30, 2011 7:41 pm

Re: RAW output information

Sat Jun 01, 2013 6:48 pm

I don't see why I cannot dig out the colour correction matrix from the tuning - I'll try remember to grab it Monday.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

poing
Posts: 1131
Joined: Thu Mar 08, 2012 3:32 pm

Re: RAW output information

Sat Jun 01, 2013 7:45 pm

Following this with interest, but it's way over my head. Once you guys get the raw into a DNG in a way a Linux noob can use it I can do some legwork and create an Adobe lens profile for the camera. Keep up the good work!

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Sun Jun 02, 2013 7:08 am

I have placed some more JPEG+RAW image files in this directory, including test charts which may be useful for determining a reasonable color matrix for a raw conversion. These were taken outdoors on a sunny California afternoon. I powered the Pi from a 12V 20 Ah battery -> 120VAC inverter -> 5V USB supply.

I hope to find some time to analyze these files and come up with some data... at some point, not sure when.

http://bealecorner.org/best/RPi/

AlanD
Posts: 4
Joined: Wed May 29, 2013 6:27 am

Re: RAW output information

Sun Jun 02, 2013 3:59 pm

The RAW extraction and DNG conversion code has been uploaded to github, that could ease collaboration:

https://github.com/illes/raspiraw

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Sun Jun 02, 2013 5:31 pm

Comparing the default JPEG output with an effort to get some reasonable color from the DNG, then sharpening quite a bit, you can see the RAW workflow has the potential to reveal more genuine detail (along with a lot of noise, and debayer artifacts of course). Makes a difference to hair texture, fabric patterns etc. First photo below is 1:1 crop from my RAW process, second is same area from the default JPEG.

Image
Image
Last edited by jbeale on Sun Jun 02, 2013 6:24 pm, edited 1 time in total.

poing
Posts: 1131
Joined: Thu Mar 08, 2012 3:32 pm

Re: RAW output information

Sun Jun 02, 2013 6:14 pm

That starts to look pretty good!

frikosal
Posts: 12
Joined: Tue May 28, 2013 7:12 am

Re: RAW output information

Wed Jun 05, 2013 6:22 pm

RAW output and manual setting of exposure time would open a lot of very interesting applications !!!
If I understood the previous messages, the situation right now is that the camera can generate RAW files but there is no way (yet) to decode them ? Are then the JPG files generated by the camera ?

User avatar
jbeale
Posts: 3492
Joined: Tue Nov 22, 2011 11:51 pm
Contact: Website

Re: RAW output information

Wed Jun 05, 2013 6:57 pm

frikosal wrote:RAW output and manual setting of exposure time would open a lot of very interesting applications !!!
If I understood the previous messages, the situation right now is that the camera can generate RAW files but there is no way (yet) to decode them ? Are then the JPG files generated by the camera ?
Well, it is not yet user friendly or quite complete but we do have the basic raw file format decoded, that is what raspiraw does and what the first image in my previous post demonstrates. The drawback is that so far, the color tuning has not been done (outside Broadcom's closed doors, at any rate) so I had to do manual color adjustments, sharpening etc. The second image is a crop straight from the JPEG file produced by raspistill along with the RAW part (raspistill --raw).

frikosal
Posts: 12
Joined: Tue May 28, 2013 7:12 am

Re: RAW output information

Thu Jun 06, 2013 7:25 am

jbeale wrote: Well, it is not yet user friendly or quite complete but we do have the basic raw file format decoded, that is what raspiraw does and what the first image in my previous post demonstrates. The drawback is that so far, the color tuning has not been done (outside Broadcom's closed doors, at any rate) so I had to do manual color adjustments, sharpening etc. The second image is a crop straight from the JPEG file produced by raspistill along with the RAW part (raspistill --raw).
Thanks !!
The camera isn't easily available here (Barcelona), otherwise I would buy one right now to test it ! :)
Perhaps the information could be converted to DNG format and then use conventional software for the adjustments ?
Still, I'm surprised that there is no official documentation available about the RAW format. The JPGs must then be generated by the camera (?).
Do you know if after connecting the camera to GPIO are some IO pins free to use, for instance to trigger the camera ?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23659
Joined: Sat Jul 30, 2011 7:41 pm

Re: RAW output information

Thu Jun 06, 2013 9:31 am

frikosal wrote:
jbeale wrote: Well, it is not yet user friendly or quite complete but we do have the basic raw file format decoded, that is what raspiraw does and what the first image in my previous post demonstrates. The drawback is that so far, the color tuning has not been done (outside Broadcom's closed doors, at any rate) so I had to do manual color adjustments, sharpening etc. The second image is a crop straight from the JPEG file produced by raspistill along with the RAW part (raspistill --raw).
Thanks !!
The camera isn't easily available here (Barcelona), otherwise I would buy one right now to test it ! :)
Perhaps the information could be converted to DNG format and then use conventional software for the adjustments ?
Still, I'm surprised that there is no official documentation available about the RAW format. The JPGs must then be generated by the camera (?).
Do you know if after connecting the camera to GPIO are some IO pins free to use, for instance to trigger the camera ?
NewIT have some camera modules for sale - they will send to Europe I think.

The GPU runs the camera, takes the images and encodes them to JPG internally using dedicated HW. They are then passed to the ARM for storing on the SD card. The RAW data is appended to the metadata if requested.

There are GPIO's free (most of them in fact)
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed. Here's an example...
"My grief counseller just died, luckily, he was so good, I didn't care."

Return to “Camera board”