**@IliasG**Why should I always prove that my understanding is correct? Though, I try to be patient. As everyone could see at

the wiki-page, the definition of a color space is:

*a color space is a color model with a certain mapping function between the color model and a certain reference color space* where a color model is

*an abstract mathematical model describing the way colors can be represented as tuples of numbers.*Hence,

**my reference to a color space in the context of the trouble is perfectly justified. We have one color space for CR2-files and another color space for DNG-files. They ARE color spaces by the definition** - they have both mathematical representations of color components AND mapping functions to an absolute color space - the sRGB. Therefore, when I found out that simple SHR by 2 is not a proper transformation between the two, I asked someone to help me to define the correct transformation. Why then A1ex started to point me out that the color space is one and the same? No, IliasG and A1ex, they are not. CR2HDR transforms one color space of CR2-files into another color space which

by the definition will

**never** be the same color space and the reason for that is the fact that the numbers in the resulting DNG which represent certain colors are different from those in the original CR2-file. Does it sound convincing now?

Of course the normalization of all the range is better than the offset but you have to know the values that DxO uses as BL & WL ..

I have checked WL&BL for this file only - they are exactly the values which are defined by Canon in Exif. Any attempt to exceed the WL by applying different ranges to multiply after normalization results in a corrupted data error in the DxO. Though, I still have another couple of files where the WL is different - it is 15092 (at ISO200) instead of 12277 (ISO100) but I will be very surprised if the DxO have another WL (no meter why).

Is the ..forged.jpeg sample from the forged.cr2 that you uploaded or from a later normalized forged.cr2 ?. Looks good to me ..

No, it is a new file with the same name - my tool uses this name-template for the resulting files!

Here is the new one if you need it.Can you describe how exactly do you normalize the values ?

Easily but using C and do not forget that it was just a test - all the values are hard-coded for the particular file. Take a look:

` val = ((val - 7964) * 40920) / 42140;`

mcu[j] = (ushort) (2047 + (val >> 2));

where the "val" is the original value from a DNG-data and "mcu[j]" is the resulting value to be compressed and saved in the forged CR2-file. 42140 is the subtraction of BL from WL for DNG's WL&BL, 40920 is the same for CR2 but multiplied by 4, and 7964 and 2047 are the BLs. As you can also see, I did not do any special roundings but that will be done in the final version (sooner or later).

You shouldn't compare the brightness of the forged.cr2 with the dual.cr2 but with a normal (single ISO) cr2 shot with the same settings and lighting ..

Ok, it was just a thought.