Custom processing for JPEG (Tone curve, CA ...)

[toinech]

According to the code it looks like it is possible to pre-process the RAW value stored in memory before it gets saved to JPEG.
For now an existing RAW file is reloaded and developed with internal settings during RAW develop. Is the code as I understood?
I am planning to add the following features:

- Custom tonal curves (for example to reduce blown out in JPEG like on the Fuji S100)
- Chromatic Aberration reduction using PTLens data base
- Filter simulation (Polarizer, Warm tone...)
- Film simulation (Velvia, Chrome....)

Does it make any sense?

Toine

[Barney Fife]

Deleted

[PhyrePhoX]

makes sense, and also it will make alot of work
what do you mean by "developed by internal settings"? development is done according to the camera's settings, e.g. whitebalance, sharpening, quality. adding additional settings there will be a huge task, i doubt it is possible, but then again there are a lot of features that wouldnt be in chdk if the devs would have "hit the wall of doubts".

[GrAnd]

adding additional settings there will be a huge task, i doubt it is possible

Anything is possible. We have RAW data and we can modify it before saving to JPG. Right now only badpixels correction uses this possibility. But it can be more intellectual processing. Anyway, it should work very quick to prevent camera from shutdown by watchdog timeout.

[mkmenuts]

it should work very quick to prevent camera from shutdown

...If only we knew how to program the DIGIC DSP...

It is capable of quite a lot, and is used in the high end cameras as well. I would guess applying a curve or a filter is peanuts for it.

If we knew what function sends the configuration to the DIGIC, we could try it with all the different options already available and  then add more.

[PhyrePhoX]

we should send  a rogue agent to canon, so he can steal a software emulator & debugger.

[Barney Fife]

Deleted

[PS]

- Something needs to be done with the lack of saturation in the shadows;

[toinech]

At first I was going to only do the same mapping for all pixels - i.e. for any pixel a specific input value will be converting to a specific value from the below table:

  outValue[inValue] 
              with inValue in the [0..1023] range
              and outValue in the [0..1023] range

Then I thought of color filters with the following table:

  outValue[colorPixel, inValue]
              with inValue in the [0..1023] range
              and outValue in the [0..1023] range
              and colorPixel in the [0..3] range or [0..2] range depending on whether it is CYMG or RGB

The problem is that I don't know how the color pixels are arranged in the file and whether it is a RGB or CYMG matrix.

Anybody knows (at least for the A610)?

Worst case I will stick with the initial - but that will be a shame.

Looks like the algo is stupid enough to eat not too much of CPU and cause time out - But who knows...

Thanks in advance for your help,

Toine

[Barney Fife]

Deleted

[toinech]

Uhhmm... unless I'm totally misunderstanding how the RAW data is being held in the camera's memory.... it should be in the format of RGBG (bayer matrix) for all of these cameras.

Aren't they all luminance values taken direct from the sensor? They just happen to have a color filter over each one. No such thing as a "colorPixel" in RAW.

Still need to find out what color filter is for which pixel. I am planning to apply a different response curve against each of those 'color filtered' pixel (e.g. the one with green filter will have the 'Green' response curve applied to).

Anyway, if the information can be read by dcraw, I'll probably have go look at the dcraw source and work from there.

Can you confirm that the CHDK RAW file is readable by dcraw?

Thanks

[GrAnd]

Uhhmm... unless I'm totally misunderstanding how the RAW data is being held in the camera's memory.... it should be in the format of RGBG (bayer matrix) for all of these cameras.

Aren't they all luminance values taken direct from the sensor? They just happen to have a color filter over each one. No such thing as a "colorPixel" in RAW.

Still need to find out what color filter is for which pixel. I am planning to apply a different response curve against each of those 'color filtered' pixel (e.g. the one with green filter will have the 'Green' response curve applied to).

RGGB Bayer matrix.
* Even lines - RGRGRG...
* Odd lines - GBGBGB...

Can you confirm that the CHDK RAW file is readable by dcraw?

Yes.

[Barney Fife]

Deleted

[toinech]

Anyway, it should work very quick to prevent camera from shutdown by watchdog timeout.

Well I finished the coding and run a couple of test - It did not timeout but it did slow down the camera quite a bit!. It seems to work however (Tried on a  1=>1 level and 1=>1/2 level conversion).

As I am not a wiz for coding C, I attached the code snip here in case anybody has an idea of how to optimize it.

Code

GeSHi (c):
unsigned short curve[4][1024]; 
// The 3 different color level conversion can be done here... 
// (we'll do twice the Green one).
// Assume to have the following matrix
// (0)(1)
// (2)(3)
 
Cut out the outdated code to make room in the post...
 
Thank you all for your input.
 
Hope that I won't have to declare this as a dead feature.
Created by GeSHI 1.0.7.20

[GrAnd]

> unsigned short curve[4][1024];
> ...
> pixVal[k]=curve[2*(i&2)+(k&2)][pixVal[k]]; // Assumme Bayer

The expression 2*(i&2)+(k&2) can has 0, 2, 4, 6 as the result, but declaration is "curve[4]".
Is it supposed to be 2*(i&1)+(k&1)?