6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Tue Jul 15, 2014 7:34 am

cartwrightluke wrote: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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: RAW output information

Tue Jul 15, 2014 7:56 am

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

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Tue Jul 15, 2014 9:14 am

jamesh wrote:EDIT: Probably should have read 6x9's post first eh!
I'm used to you ignoring me! ;)
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

User avatar
TheAlbatross
Posts: 7
Joined: Wed Jul 23, 2014 7:10 pm

Re: RAW output information

Wed Jul 30, 2014 1:41 pm

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?
Last edited by TheAlbatross on Wed Jul 30, 2014 2:58 pm, edited 2 times in total.

ethanol100
Posts: 585
Joined: Wed Oct 02, 2013 12:28 pm

Re: RAW output information

Wed Jul 30, 2014 2:32 pm

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?

User avatar
TheAlbatross
Posts: 7
Joined: Wed Jul 23, 2014 7:10 pm

Re: RAW output information

Wed Jul 30, 2014 9:07 pm

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
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: RAW output information

Tue Nov 25, 2014 3:48 am

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
Posts: 25
Joined: Fri Nov 07, 2014 7:45 am

Re: RAW output information

Wed Nov 26, 2014 2:51 pm

cartwrightluke wrote: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

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

Re: RAW output information

Wed Nov 26, 2014 3:03 pm

> Using "raspistill --raw -o test.jpg" gives wrong colors, while using "raspistill --raw -hf -o test.jpg" gives correct colors.
6by9 wrote: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
Posts: 25
Joined: Fri Nov 07, 2014 7:45 am

Re: RAW output information

Wed Nov 26, 2014 3:13 pm

jbeale wrote: 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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 23637
Joined: Sat Jul 30, 2011 7:41 pm

Re: RAW output information

Wed Nov 26, 2014 3:24 pm

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

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Wed Nov 26, 2014 3:30 pm

bablokb wrote: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:
6by9 wrote: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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

bablokb
Posts: 25
Joined: Fri Nov 07, 2014 7:45 am

Re: RAW output information

Wed Nov 26, 2014 3:47 pm

6by9 wrote:
bablokb wrote: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:
6by9 wrote: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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Wed Nov 26, 2014 4:14 pm

bablokb wrote: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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: RAW output information

Wed Nov 26, 2014 4:59 pm

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
Posts: 25
Joined: Fri Nov 07, 2014 7:45 am

Re: RAW output information

Wed Nov 26, 2014 5:00 pm

6by9 wrote: "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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Wed Nov 26, 2014 5:25 pm

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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

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

Re: RAW output information

Wed Nov 26, 2014 8:37 pm

bablokb wrote:
6by9 wrote:
bablokb wrote: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:
6by9 wrote: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.
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."

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

Re: RAW output information

Thu Nov 27, 2014 7:23 am

jamesh wrote: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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Thu Nov 27, 2014 9:13 am

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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

bablokb
Posts: 25
Joined: Fri Nov 07, 2014 7:45 am

Re: RAW output information

Thu Nov 27, 2014 10:22 am

6by9 wrote: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
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Thu Nov 27, 2014 10:44 am

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).
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: RAW output information

Thu Nov 27, 2014 12:37 pm

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
out800x600.jpg (60.45 KiB) Viewed 3153 times
PS: Now I think I know why my red car was so dark :)

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 7275
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: RAW output information

Thu Nov 27, 2014 1:56 pm

tchiwam wrote: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.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

tchiwam
Posts: 43
Joined: Mon Nov 24, 2014 4:01 pm

Re: RAW output information

Thu Nov 27, 2014 7:12 pm

6by9 wrote: 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.

Return to “Camera board”