RAW output information

[6by9]

I wanted to ask whether there has been a significant change to the way in which raw data is stored or captured?
I am attempting to capture raw data "raspistill --raw -o test.jpg" and convert it to dng using raspi_dng "raspi_dng test.jpg test.dng".
The scene shown is a classic colourchecker card and a miniature colourchecker white balance card, illuminated with an incandescent lamp. However, I have an extreme purple / green tinge to the image that I cannot seem to discern the cause of. The JPEGs look fine, even if the white balance is a little off.
I was able to open the images from http://bealecorner.org/best/RPi/ using raspi_dng / ufraw without this problem.

I'd say you've got the Bayer order wrong, probably red/blue swapped as getting the greens wrong give some really strange images. NB The Bayer order does change with any flips applied as the sensor just changes the readout direction, so you can either look at selecting the correct order in the converter, or add H & V flips to your raspistill command line.

[jamesh]

That looks like you have got the wrong bayer order. I have a recollection if you have H or V flips on the bayer order will change. Try some different values for order (and H/V flip) to see what happens.

EDIT: Probably should have read 6x9's post first eh!

[6by9]

EDIT: Probably should have read 6x9's post first eh!

I'm used to you ignoring me!

[TheAlbatross]

I'm trying to install raspi_raw on my pi, and it's the first time I'm working with c files so I'm probably doing multiple things wrong, haha. I worked through a few problems, but now I'm trying "make" and getting this error:

Code: Select all

raspi_dng.c: In function "main":
raspi_dng.c:143:42: error: "PHOTOMETRIC_CFA" undeclared (first use in this function)

Then there's a couple other "undeclared" errors.

Elsewhere I am getting segmentation fault during the libtiff make:

Code: Select all

../lib tool: line 472:  8449 Segmentation fault  ( g Mil=60; unspent MAIL ) || exit ) > /dev/null 2>&1

And another segmentation fault following, pointing to line 371. Could someone walk through the installation procedure for a grateful newbie?

[ethanol100]

So you have used:

Code: Select all

#need library
sudo apt-get install libjpeg-dev
#clone code
git clone https://github.com/illes/raspiraw
cd raspiraw
make

the make will first download and compile libtiff locally(which includes the definition of "PHOTOMETRIC_CFA"). What is the exact message when the build fails?

[TheAlbatross]

Thanks ethanol100! Repeated "make" attempts resulted in different errors, so I persisted until the installation completed successfully. Ghosts in the machine, haha. (Probably more like interdependencies getting sorted out, but that's less fun.)

[tchiwam]

Hello and thank you for the raw to dng code.

I was wondering when I look trough it

Is this OK ? Is the tiff only 8 bit ? Or am I confused ?
TIFFSetField (tif, TIFFTAG_BITSPERSAMPLE, 8);

It's not that important for me as I will simply dump the data to a file and read it with matlab, R or octave, which ever I will pick 1st...


Edit : Yes, that is only for the thumbnail....

[bablokb]

I wanted to ask whether there has been a significant change to the way in which raw data is stored or captured?
I am attempting to capture raw data "raspistill --raw -o test.jpg" and convert it to dng using raspi_dng "raspi_dng test.jpg test.dng".
...
However, I have an extreme purple / green tinge
...
I was able to open the images from http://bealecorner.org/best/RPi/ using raspi_dng / ufraw without this problem.

This question has been raised before, but has not really been answered: has there been a change in the way the raw data is read from the sensor? Using "raspistill --raw -o test.jpg" gives wrong colors, while using "raspistill --raw -hf -o test.jpg" gives correct colors.

I'm using dcraw to convert the raw-files to tif, and it works fine for "old" images, e.g. those from
http://bealecorner.org/best/RPi/. Colors are again fine after the horizontal flip.

As we all know there were changes, e.g. the model in the exif-tags for the "old" images is "ov5647" and in newer images it is "RP_OV5647". That's btw. the reason why dcraw claims not to be able to convert raw-images from the raspi-module.

Bernhard

[jbeale]

> Using "raspistill --raw -o test.jpg" gives wrong colors, while using "raspistill --raw -hf -o test.jpg" gives correct colors.

NB The Bayer order does change with any flips applied as the sensor just changes the readout direction, so you can either look at selecting the correct order in the converter, or add H & V flips to your raspistill command line.

This seems to address the difference you note.

[bablokb]

This seems to address the difference you note.

No, this doesn't. To get correct colors, I have to flip the image which is not what I want (why should I want flipped images?). I assume you did not have to flip the images for your own raw-files to get correct colors? You just used plain "raspistill --raw -o ..."?

Bernhard

[jamesh]

When you do a flip on the sensor the bayer order changes as it is read from the sensor, and you get exactly what comes off the sensor. You need to accommodate that in what ever code you are using to handle the raws.

[6by9]

No, this doesn't. To get correct colors, I have to flip the image which is not what I want (why should I want flipped images?). I assume you did not have to flip the images for your own raw-files to get correct colors? You just used plain "raspistill --raw -o ..."?

Please reread the original comment:

NB The Bayer order does change with any flips applied as the sensor just changes the readout direction, so you can either look at selecting the correct order in the converter, or add H & V flips to your raspistill command line.

Two options listed. You don't want the flips so the second isn't suitable, hence you'd better look at the first.

[bablokb]

No, this doesn't. To get correct colors, I have to flip the image which is not what I want (why should I want flipped images?). I assume you did not have to flip the images for your own raw-files to get correct colors? You just used plain "raspistill --raw -o ..."?

Please reread the original comment:

NB The Bayer order does change with any flips applied as the sensor just changes the readout direction, so you can either look at selecting the correct order in the converter, or add H & V flips to your raspistill command line.

Two options listed. You don't want the flips so the second isn't suitable, hence you'd better look at the first.

I think you don't understand my point. When I look at all the posts here, there was a lot of analysis done by JBeale and AlanD on the format of the raw data. None of these posts mentioned the need to flip the image, so I assume the analysis was done for straightforward raw-images.

AlanD has written a converter to dng which apparently worked fine https://github.com/illes/raspiraw. Dave Coffin has integrated similar code to dcraw, that code also worked fine. Note that you cannot "select" the correct order in these converters.

Suddenly both programs don't work anymore but give wrong colors. Flipping is a workaround. Changing the C-code of the converters is also a workaround (although they would then no longer work anymore for old images). But the question remains: why do I suddenly need a workaround?

Bernhard

[6by9]

I think you don't understand my point. When I look at all the posts here, there was a lot of analysis done by JBeale and AlanD on the format of the raw data. None of these posts mentioned the need to flip the image, so I assume the analysis was done for straightforward raw-images.

AlanD has written a converter to dng which apparently worked fine https://github.com/illes/raspiraw. Dave Coffin has integrated similar code to dcraw, that code also worked fine. Note that you cannot "select" the correct order in these converters.

Suddenly both programs don't work anymore but give wrong colors. Flipping is a workaround. Changing the C-code of the converters is also a workaround (although they would then no longer work anymore for old images). But the question remains: why do I suddenly need a workaround?

"Suddenly"? The camera firmware hasn't changed at all since the end of August. I don't recall the sensor driver having changed for a long time - I have a vague recollection of fixing up the flips code because it was totally wrong, but that was probably a year ago. It is now correct, so shouldn't change again.
If you want any sensible investigation of the firmware, then you need to narrow down your timeframe for when you believe it changed.

Please bear in mind that these raws have been used for automatic analysis, so one might surmise that the Bayer order was contained in the 32kB (or is it 64kB - I can't remember) header between the end of the JPEG and the start of the raw. I couldn't possibly comment.

[jbeale]

When I started looking at RAW decoding and capturing RAW images, it was 25 May 2013. http://www.raspberrypi.org/forums/viewt ... 18#p356571

But the following week, I see I made this comment in another thread: http://www.raspberrypi.org/forums/viewt ... 27#p360746

Postby jbeale » 31 May 2013 00:24 ...and don't forget with the new updated firmware, you don't need to do the horizontal flip anymore- if you do, you'll get a mirror-image output.

suggesting that the RPi firmware behavior regarding the default for horizontal flip changed right around that time.

[bablokb]

"Suddenly"? The camera firmware hasn't changed at all since the end of August. I don't recall the sensor driver having changed for a long time - I have a vague recollection of fixing up the flips code because it was totally wrong, but that was probably a year ago. It is now correct, so shouldn't change again.
If you want any sensible investigation of the firmware, then you need to narrow down your timeframe for when you believe it changed.

We have a report of success on this forum from June 5, and of a failure on July 14. But indeed, "suddenly" is vague since we don't know which firmware versions the posters were actually using. And the images posted from JBeale are quite old.

I will follow your suggestion and investigate if the header has any useful information.

Bernhard

[6by9]

https://github.com/raspberrypi/firmware ... cdc7ed8d21
24 May 2013 "firmware: Fix for unwanted hflip in camera output"

Anyone who is still running firmware that is 18 months old really deserves their heads examining. The number of improvements and fixes since means it is a crazy thing to do.
In which case it is sensible to fix both raspiraw and dcraw to work with the updated and correct Bayer order values. Even better if you do actually reverse engineer the header to get them to extract the correct order.

[jamesh]

No, this doesn't. To get correct colors, I have to flip the image which is not what I want (why should I want flipped images?). I assume you did not have to flip the images for your own raw-files to get correct colors? You just used plain "raspistill --raw -o ..."?

Please reread the original comment:

NB The Bayer order does change with any flips applied as the sensor just changes the readout direction, so you can either look at selecting the correct order in the converter, or add H & V flips to your raspistill command line.

Two options listed. You don't want the flips so the second isn't suitable, hence you'd better look at the first.

I think you don't understand my point. When I look at all the posts here, there was a lot of analysis done by JBeale and AlanD on the format of the raw data. None of these posts mentioned the need to flip the image, so I assume the analysis was done for straightforward raw-images.

AlanD has written a converter to dng which apparently worked fine https://github.com/illes/raspiraw. Dave Coffin has integrated similar code to dcraw, that code also worked fine. Note that you cannot "select" the correct order in these converters.

Suddenly both programs don't work anymore but give wrong colors. Flipping is a workaround. Changing the C-code of the converters is also a workaround (although they would then no longer work anymore for old images). But the question remains: why do I suddenly need a workaround?

Bernhard

As I understand it, you don't need a workaround, you need the raw programs to be bug fixed. I don't believe this is a problem with the raw data, but in the post processing being done by third party code. The raw data WILL change bayer order depending on the hflip, that's just how it is. The original GPU code released had a bug in the hflip/vlip handling that was fixed in May 2013, I presume the other programs have not been updated since then, or were only tested with one particular bayer order.

[jbeale]

As I understand it, you don't need a workaround, you need the raw programs to be bug fixed. I don't believe this is a problem with the raw data, but in the post processing being done by third party code. The raw data WILL change bayer order depending on the hflip, that's just how it is. The original GPU code released had a bug in the hflip/vlip handling that was fixed in May 2013, I presume the other programs have not been updated since then, or were only tested with one particular bayer order.

I think that's about the size of it. I haven't worked with raw since my initial experiments in 2013, so I suspect my old software just worked with the "old" bayer order. Simple enough to fix I think, but I haven't had the occasion to do so.

[6by9]

Looks trivial enough.
https://github.com/illes/raspiraw/blob/ ... dng.c#L147 and I'd guess the new Bayer order should be "\001\002\0\001"
For dcraw, http://www.cybercom.net/~dcoffin/dcraw/dcraw.c line 8170 wants to be changed so filters is (probably) 0x49494949 instead of 0x16161616 (see lines 213-221 for the layout of each of the filter values). It'd be worth amending line 8163 to allow the updated model string too.

[bablokb]

Looks trivial enough.
https://github.com/illes/raspiraw/blob/ ... dng.c#L147 and I'd guess the new Bayer order should be "\001\002\0\001"
For dcraw, http://www.cybercom.net/~dcoffin/dcraw/dcraw.c line 8170 wants to be changed so filters is (probably) 0x49494949 instead of 0x16161616 (see lines 213-221 for the layout of each of the filter values). It'd be worth amending line 8163 to allow the updated model string too.

I will try that. But can anybody confirm my observations with their camera?

BTW: I found the embedded color-matrix in the EXIF-data:

Code: Select all

exiftool -b -makernoteunknowntext RAW0132.jpg 
ev=-1 mlux=-1 exp=488 ag=256 focus=255 gain_r=1.429 gain_b=1.234 greenness=3 ccm=7974,-3320,-554,-1192,5658,-366,328,-2986,6760,0,0,0 md=4 tg=390 390 oth=0 0 b=0 f=390 390 fi=0 ISP Build Date: May 24 2013, 16:50:34 VC_BUILD_ID_VERSION: 6676ab07e56aeec897f23d09b8fb87b55cbec981 (clean) VC_BUILD_ID_USER: dc4 VC_BUILD_ID_BRANCH: dev

Plugging the values of ccm into dcraw and using gain_r and gain_b really improves the results. I will try to changes the programs so they read these values, since currently they are hardcoded so I need to change the source and recompile for every image.

[6by9]

So those are the CCMs and AWB gains that the internal algorithms have chosen. Half the point of capturing raws is that you can tinker with them, as otherwise you are just going to recreate the same image as the GPU (although you could tweak values in other parts of the processing chain).

[tchiwam]

What is the currently fastest way to get raw images back to back ? Simply trying to get the trails a bit better... Burst mode ?

Using ISO 800 @ 6s
Lens F2.0 4mm

out800x600.jpg (60.45 KiB) Viewed 3246 times

PS: Now I think I know why my red car was so dark

[6by9]

What is the currently fastest way to get raw images back to back ? Simply trying to get the trails a bit better... Burst mode ?

Using ISO 800 @ 6s
Lens F2.0 4mm

Do you really want the raw Bayer, or is combining the YUV sufficient? Have a read of http://www.raspberrypi.org/forums/viewt ... 50#p588889 and the image slightly further down that page.

[tchiwam]

Do you really want the raw Bayer, or is combining the YUV sufficient? Have a read of http://www.raspberrypi.org/forums/viewt ... 50#p588889 and the image slightly further down that page.

I've been trough the whole thread And yes I want the raw bayer. I have my own dead pixel, dark frame, white frame (log (m)-(log(bg))/(log(w)-log(bg)) )*fn

Ideally shooting scanned lines continously with as small of a gap between each frame.