Green tones into final raw.

Submitted by juanmafont on

Helo, i'm developing a software that mix some raw files and save into dng. The problem is that into end raw imagen had green tonnes.

What i do.

Sort images by exposition time, less exposed first and calculate a correct factor (RFC) based into relative exposition between them, so:

If a have 3 images (first image, image0, less exposed):

image0 RFC[0]=1.0
image1 RFC[1]=0.5336
image2 RFC[2]=0.2476

And RFC[0]... RFC[2] are relative correction factor based into his exposition ( brightness.)

The final image will be the result of mix this 3 images. There will be 2 situations for every 'pixel-cell' of the destination raw (save into dng format)

Situation A. The result cell will be a simple cell , and came from a unique cell of the originals images.

Situation B. The result cell will be a mix cell, and came from 2 cells of the original cells.

Cell type A (simple)

dest. cell = cell * RFC[x]

Cell type B (mix)

dest. cell = cell1 * RFC[x] + cell2 * RFC[x+1]

This software was ok when the sources was tiff files but i got green cells if i try develop and work with raw files.

I'm working with simple bayer pattern raw files like CR2.

RGRGRGRGRGRGRG
GBGBGBGBGBGBGB
RGRGRGRGRGRGRG
GBGBGBGBGBGBGB

The RFC are calculate only with R,G1 and B values (not used G2) but i got the same result if included G2.

What happen ?

Is imposible multiplicate cells of a destination raw before demosaicing by different numbers (RFC) without obtains green tonnes ?

How can I get this...

This technique worked with tiff files.

Forums: 

I guess, for correct output

Submitted by lexa on

I guess, for correct output you need to have sum of weight factors equal to 1.0 in each pixel

-- Alex Tutubalin @LibRaw LLC

Thanks, lexa. I do this

Submitted by juanmafont on

Thanks, lexa.

I do this when is it a mixed pixel.

// It's a mix pixel from various images
gray16_pixel1 = *vct_gray16ViewSrc_iterator[i-1];
gray16_pixel2 = *vct_gray16ViewSrc_iterator[i];
drFC1 = vectorRFC[i-1];
drFC2 = vectorRFC[i];
m2 = static_cast<double>(*dbl_vct_it) - static_cast<double>( i );
m1 = static_cast<double>(1) - m2;
mul1 = drFC1 * m1;
mul2 = drFC2 * m2;
 
gray16_pixel1 = gray16_pixel_t(round( static_cast<double>(gray16_pixel1) * mul1 +
                                                                static_cast<double>(gray16_pixel2)   * mul2 ) );

If you look m1 and m2 they are weight compensed to 1 in a cell. see m1= 1 - m2

Sorry, when you talk about 'pixel' ... it is a cell, like 'R' or is it about four cell like the group(R,G1,B,G2) ?

NOTE: I use gray16_pixel_t because are simple values, from 0 to 65535 and dont have components (like red,green,blue)

Yes, m1 = 1 - m2. But

Submitted by lexa on

Yes, m1 = 1 - m2. But drFC1*m1 + drFC2*m2 will generally not being equal to 1.0

-- Alex Tutubalin @LibRaw LLC

Ummm, let's me think about

Submitted by juanmafont on

Ummm, let's me think about that...

RFC[] are calculate using: (for 3 images, sorted by exposition, lower exposition first, and so ... )

RFC[0]= 1.0 always
RFC[1]= SUM_A / SUM_B * RFC[0]
RFC[2]= SUM_B / SUM_C * RFC[1]

SUM_A is R,G1 and B from image 0
SUM_B is the same from image 1
SUM_C is the same from image 2

Then this must be refact so RFC[0] + RFC[1] + RFC[0] = 1.0 ?

Well, looks like the greens

Submitted by juanmafont on

Well, looks like the greens that appear are those of the raw nature of the files, I mean:

If I catch any raw file, and modify the values of all cells ('or pixels') such as multiplying by a value less than 1, it appears greenish around the resulting raw file. All this before demosaicing.

I have a suspicion it's because in a raw, there are 2 green cells for each cell red and blue.

Anyone can confirm me this?

Can you lower the brightness of a raw without the appearance of these greens, or what is the same I can multiply by something less than 1 without getting this effect?

Thank you.

1) You do your calculations

Submitted by lexa on

1) You do your calculations before white balance procedure, or after that?
2) What WB method is used

-- Alex Tutubalin @LibRaw LLC

Sorry, but the method you are

Submitted by ib on

Sorry, but the method you are trying to use is wrong. Please have a look at how it is accomplished in, say, Fuji S5. You need to replace noisy and blown pixels altogether. There is no point in mixing good with bad.

If you are smart, do it on per channel basis.

Finally, you may want to check if you understand white balance well enough. Raw without white balance application looks green, search for UniWB.

--
Iliah Borg