RAW output information

[Preamp]

That color matrix is working great! I've put it into one dng via hex-editor, but implementing it in the code right from the start should be even better .

Here it is again in plain text:

Code: Select all

1,2782
-0,4059
-0,0379
-0,0478
0,9066
0,1413
0,134
0,1513
0,5176

And ready to be pasted via hex-editor:

Code: Select all

ee31000010270000
25f0ffff10270000
85feffff10270000
22feffff10270000
6a23000010270000
8505000010270000
3c05000010270000
e905000010270000
3814000010270000

Not sure if it's perfect though, since the camera-wb is still off, but automatic wb works fine.

[jamesh]

Are you guys saying that the CCM you have is better than the results you get using the internal one (letting GPU do all the work)? If that's the case I can put those numbers in to the GPU firmware to see if the images are better. Trouble is that might cause following on tuning issues, but might be worth a try.

[Preamp]

Are you guys saying that the CCM you have is better than the results you get using the internal one (letting GPU do all the work)?

No, but it's better than the "1 0 0 0 1 0 0 0 1" used by raspidng.
But what about the other way round - can you get the correct matrix out of the firmware so that @jbeale can put it in his tool?

[jbeale]

Are you talking about the code done by AlanD here? http://www.raspberrypi.org/forums/viewt ... 25#p362257
I don't actually know how to upload code to github myself.

I have some color charts and an early version of Imatest (when it was still affordable to individuals) which in theory could allow calculating the matrix, or at least doing some iterative improvements, I haven't had the time to figure it out though. Certainly we ought to use a good approximation to the real matrix, as opposed to the default / no matrix as used now.

[Preamp]

Are you talking about the code done by AlanD here? http://www.raspberrypi.org/forums/viewt ... 25#p362257

Yepp. Sorry, I got you confused .

How do you calculate a color matrix from your test shots? I'm not deep enough into color management to know how to do that...

[jbeale]

It is not exactly simple. There is some (very expensive) software that does it for you, see for example http://www.imatest.com/docs/colormatrix/
Here is a paper explaining one algorithm to calculate it: http://www.its.bldrdoc.gov/publications/04-406.aspx

I have seen it claimed that Adobe DNG Profile Editor can do this, and it is a free download. I have never tried it, and it only runs on Mac OS
http://www.adobe.com/support/downloads/ ... ftpID=5493

[Preamp]

John, you're a genius!
There is a windows version of the DNG profile editor here:
http://www.adobe.com/support/downloads/ ... ftpID=5494

Unfortunately it has some complaints about both of your MacBeth images. The one with the light background has a color cast in a gray patch and the one with the dark background is clipped .

Is there a way for manual exposure adjustment using the rpi cam? Are you able to re-do some color checker shots?
I just ordered my cam, but I don't own a color checker...

[Preamp]

Received my cam today (ordered it yesterday, wow!) and made some initial tests.

First thing I noticed is that my cam seems to have a different bayer pattern. Raspidng uses BGGR, which works fine with the samples from John. My files, however, need GBRG to render correctly. Well, correctly is a little optimistic, since the color matrix is a little off, too.

Do you think it's possible that every camera (or every batch maybe) gets factory calibrated with its own camera matrix?? The jpegs look fine, so there has to be some magic in there...

[jamesh]

No, they don't get calibrated in the factory. There is a hardwired set of CCM's.

[Preamp]

Unfortunately the lens correction data is hardwired, too .
I unscrewed the tiny little lens and replaced it by a 35mm-SLR lens (58mm Helios 44-7). The results are awful - even the raw data is showing this strange colored vignette .

[jamesh]

They are indeed hardcoded at the moment. There is a vague possibility that we will be able to add some automatic lens shading correction (we need to merge in some changes). Not sure of a timescale, and it might need tuning anyway.

Things a re a bit hectic at Broadcom at the moment, so cannot give any schedules for anything.

[Preamp]

And will you be able to let raspistill put out the raw data without that correction already applied? That would be crucial to have a real benefit of the raw data and greatly enhance the usability (read hackability) of the cam!

[6by9]

The raw image from Raspistill is without any processing (and that includes lens shading) applied. Always has been, always will be.

The issue of changing bayer order is going to be due to using flips - they normally just change the sensor readout directions, and therefore the pattern will have changed.

[Preamp]

The raw image from Raspistill is without any processing (and that includes lens shading) applied. Always has been, always will be.

And what causes the strange vignette in the picture I posted above? It does actually look a bit like IR, but why isn't it uniform? I couldn't find a separate hot mirror beneath the lens and the sensor surface itself seems to be IR-coated.
Is this a problem of the angle of incident with which the light hits the sensor? The beam on such a small area from a SLR lens with a flange distance of several 10mm should be pretty telecentric; the original lens probably is not. Do you have any facts about that?
If this is the case, then the NoIR with an additional hot mirror is the way to go, I think .

[poing]

The raw image from Raspistill is without any processing (and that includes lens shading) applied. Always has been, always will be.

This image is derived from RAW using the AlanD method; I took it without a lens and only a neutral paper napkin (measured it with a photographic color temperature meter) over the lens opening to diffuse the direct sunlight. Seems there's some processing (negative vignetting) going on:

cam03_nolens_small.jpg (22.41 KiB) Viewed 5455 times

[6by9]

This image is derived from RAW using the AlanD method; I took it without a lens and only a neutral paper napkin (measured it with a photographic color temperature meter) over the lens opening to diffuse the direct sunlight. Seems there's some processing (negative vignetting) going on:

You're dealing with a relatively cheap sensor aimed at the mobile phone market. On the Pi the sensor is doing almost no work except for reading out pixel data. The data written out as the raw file is the data as received from the sensor before it is touched by the Broadcom ISP.
Your vignetting is quite probably slight sensitivity variation over the sensor area but it is NOT deliberate processing.

If it is an issue to you, pay more money for something that is designed to do what you want - the Pi camera is sold as a complete module, not a module with an interchangeable lens.

[poing]

Hm OK, could also be reflections from the inside of the lens mount I guess.

[Preamp]

After some googling I'm pretty sure what we're dealing with here.
I think it's a "Chief Ray Angle Correction" for the used lens. In other words: the microlenses on the outer sensels are shifted away from the sensel's center to compensate for the (probably huge) CRA of the tiny lens. You can read about it here: http://space.ednchina.com/Upload/2009/9 ... 1f128f.pdf
Apparently even digital Leica range finders suffer from this .

To the Engineers: Thank you for sharing your knowledge and please don't feel offended! Of course this module was not designed for interchangeable lenses, but still it's good to know what it's capable of and what it's not

[poing]

I think you're right. Great opportunity for the Foundation to launch a tele-lens-capable camera without a lens

[jamesh]

re: lens shading and vignetting.

See here http://en.wikipedia.org/wiki/Vignetting for starters and here for seconds http://en.wikipedia.org/wiki/Chromatic_aberration

These sensors are tiny. At the edge of the sensor the light is coming into the diodes at a very different angle to the centre of the sensor. In addition, the light has also been bent further by the lens, and has to travel further. So, there is a clear optical difference at the edges of the sensor to the centre, and this can be seen in the artefacts seen in the image above.

[Preamp]

@poing did his shot without any lens, so there was nothing there that could have caused vignetting or CA. Because of that, the chief ray angle with which the light hit the sensor was basically 0° over the whole sensor area. On a sensor without any microlenses this would have led to a uniform illumination, but in this case the microlenses away from the center of the sensor are shifted, so that the maximum efficiency is reached only with light coming in at an angle rather than perpendicular.
Here's the Leica sample showing the same kind of coloration at the edge: http://diglloyd.com/articles/LeicaM/Lei ... Angle.html

EDIT: Here's a statement from the document I linked earlier (which is from the manufacturer of the sensor, BTW):
- For OVT (CRA=25°) FSI sensors, the on-axis pixels reach the peak quantum efficiency at 0°CRA
- Corner pixels reach peak quantum efficiency at 25°CRA matching the lens CRA of 25°

[jbeale]

Just FYI, for anyone interested in playing with raw data, the Picamera library for controlling the camera via a Python program, now also supports raw capture in version 1.5 just released. Here is an example program: http://picamera.readthedocs.org/en/rele ... a-captures

[Stigmen]

I'm sorry I'm pretty much asking for basics here. I am tying to process raw image files with Matlab. So far I got the rows and colums separated and by plotting one of the first 4 of 5 bytes I get an image.. sort of. From what I see the 4 bytes seem not to represent BGGR Channels/subpixel

I read the thread and the c code a couple of times but I must have missed the point about the debayer progress:

Given the 5 Bytes (or the first 4 to keep it simple) and the color Matrix, how can you extract a colour channel?

[6by9]

SMIA CCP2 spec is online at http://www.sunex.com/sima/smia_ccp2_spe ... on_1.0.pdf Section 7.9 describes the RAW10 format - the least significant 2 bits of each pixel are sent in the 5th byte.
You're misunderstanding the Bayer pattern. Reading the raw data in a linear fashion will give you a line of either BG, GB, RG, or GR. The next line will be a whole line of GR, RG, GB, or BG so that every 2x2 grid is a Bayer cell.

[cartwrightluke]

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.