70D Dynamic Range is actually great, despite what DXOMark says

Started Jan 21, 2014 | Discussions thread
janfi67 Junior Member • Posts: 35
Re: 70D Dynamic Range is actually great, despite what DXOMark says

janfi67 wrote:

TTMartin wrote:

According to DxOMark every Canon dSLR they have tested basically has the same per pixel dynamic range. That includes the original 2003 APS-C Digital Rebel and the full frame 1D X. Any changes in dynamic range scores is because DxOMark uses a formula that changes the print dynamic range score based on the number of megapixels.

So you can choose to believe DxOMark, or you can look at possible flaws that would explain these seemingly erroneous results.

There is a group here that believe the results are accurate and can be explained by noise from the external analog to digital converter, I don't believe this is correct.

Oh yes, please... prove me that my lovely Canon camera is better than DxO and other say. Explain me why they are all wrong and why the DR is far better than 11EV. I can't wait to know.

Yes, keep believing that the Canon 6D, 1DX and every other Canon dSLR using the CR2 file format including the original 2003 APS C Digital Rebel have basically the same per pixel DR, because DxOMark says so, despite substantial evidence to the contrary.

I would be happy to believe you, but your argument is still rather weak. Thanks for your assertion but you didn't provide any substantial evidence.

First DxOMark attempts to measure sensor noise by looking at the RAW file. This basic concept is inaccurate because manufactures can apply different amounts noise reduction prior to the RAW file being written. Case in point the Nikon D300, Nikon D300s, and the Nikon D90 all use the same sensor. Yet the Nikon D90 scores higher than the Nikon D300 and Nikon D300s, because the D90 applies more noise reduction PRIOR to the RAW file being written.

Hummm... Like all photographers, I can only use the RAW files, not the sensor output. So I only care about what the RAW file contains and what I can do with it.

And as said previously, you're wrong. D300 and D90 don't use the same sensor.

Then you should care that Canon Digital Photo Professional (DPP) does a better job at decoding the RAW file, and not what testing sites using a 3rd party RAW converter say.

That's your opinion, and I respect it, even if mine is different. By the way, I don't need testing sites to know which RAW converter I prefer. You'll notice the subtle difference, I dot not affirm one is better than the others, I'm just saying I prefer one to the others.

Camera that use Sony sensors apply noise reduction at the sensor level prior to the RAW file being written.

Do you think Canon doesn't apply some kind of noise reduction prior the RAW file being written? Never heard of CDS? It's embedded in the sensor itself (including the Canon ones) and it's a noise cancellation system.

If all manufactures apply some noise reduction prior to the RAW file being written then what exactly is DxOMark testing? Certainly not the sensor performance like they claim.

I do not care about what DxOMark is testing. I just highlighted that Canon do the same kind of things than Sony in this area.

Canon embeds information in the RAW file to be used by their RAW converter DPP. Third party RAW converters don't take advantage of this information. For example Canon masks portions of the edge of their sensor, to provide information on both row and column sensor noise, 3rd party RAW converters like the one used by DxOMark do not use this information.

You seems misinformed. Take a look at public domain RAW converters sources and documentation. After reverse engineering they use data provided by the masked portions of the edge of the sensor to reduce the noise.

When I looked at DCRAW, it did not. If I am wrong please post the portion of code that uses it.

That's easy, hare are some extracts of an old, but easy to understand version of Dcraw sources:

unsigned black, cblack[8];

void CLASS lossless_jpeg_load_raw()
for (jrow=0; jrow < jh.high; jrow++) {
rp = ljpeg_row (jrow, &jh);
for (jcol=0; jcol < jwide; jcol++) {
val = *rp++;
if ((unsigned) (row-top_margin) < height) {
c = FC(row-top_margin,col-left_margin);
if ((unsigned) (col-left_margin) < width) {
BAYER(row-top_margin,col-left_margin) = val;
if (min > val) min = val;
} else if (col > 1 && (unsigned) (col-left_margin+2) > width+3) // end of the row
cblack[c] += (cblack[4+c]++,val);
} // end of for (jcol
} // end of for (jrow
ljpeg_end (&jh);
FORC4 if (cblack[4+c]) cblack[c] /= cblack[4+c];

As you can see, cblack is computed using values of the masked portions of the sensor.

In the latest version it is located in the crop_masked_pixels class and it uses mblack array.

And how can you tell than products like DxO or ACR don't use them?

Because their conversions contain more noise than those converted with Canon DPP.

No, seriously, I was waiting for a more elaborate answer, not for this rather weak reasoning.

Are you aware of all the details about CR2 format Canon discloses only under NDA?

Are you? Can you name someone other than a Canon employee who is?

Once again, you're not answering to the question.

By reverse engineering, at least one public domain RAW converter use some proprietary information of the RAW file . Don't you think Adobe or DxO people cannot do at least the same?

And anyone working on reverse engineering the CR2 file would be in violation of their NDA, so any implication that you or anyone else has more knowledge about what Canon actually does in the CR2 file is just a red herring.

As usual, you don't understand what you are writing. Do you know what a NDA is? Not obviously. A Non Disclosure Agreement engage you to not disclose information given by the owner of this information. In case of reverse engineering, there is no NDA! You may in some cases violate intellectual properties laws, but obviously not a NDA that you have not signed.

Because their conversions contain more noise than those converted with Canon DPP.

Always the same assertion. That's rather weak.

Third party RAW converters attempt to directly read portions of the Canon CR2 file and directly convert them to RGB. There are several problems with this, first according to Canon's Chuck Westfall Canon RAW data is recorded in sYCC and not RGB.

This is one of the funniest part of your post, and once again, you're wrong.

Do you realize what does recording RAW data in sYCC mean? I don't think so, despite the picture you post.

An sYCC encoded image is obtained AFTER DEMOSAICING the CFA RGB data. It's not a RAW format.

This is where your thinking falls apart. You assume because the original Canon CRW format and Nikon NEF used a certain format to encode their RAW data that Canon had to be constrained by that when they developed the CR2 format. A RAW format is what the manufacturer wants to use to maintain all the data from the sensor. Sorry, the manufacturer does not have to be constrained by your definition of how sensor data is maintained in the RAW file.

I'm sorry, but your answer is totally off topic and you're wrong. Canon DSLR RAW data for the full size raw are CFA RGGB data, not sYCC data. You don't believe me? Read Understanding What is stored in a Canon RAW .CR2 file, How and Why. If you don't know where to find this information, it is §3.4.4. Decoding image data :"The output of the jpeg lossless decompressing is a Color Filter Array (CFA) picture."

Switch a Nikon D300 to 14 bit NEF and it slows to 3 fps, the Nikon D7100 isn't much better.

So what? What is the relation with Nikon? We're talking about how are encoded Canon CR2 files.

So you don't think it's possible that when Canon developed the CR2 file format that they recognized that in order to move 14 bit RAW data more quickly that they had to find a different way to encode it?

try to understand Understanding What is stored in a Canon RAW .CR2 file, How and Why.

For your information, Canon sRAW formats use YCC encoding, but they aren't RAW format per se, and they are not used by DxO to perform their tests. It's a kind of lossless jpeg, but using 15 bits data for the 3 components, Y, Cr and Cb, not 8 bits like traditional jpeg.

sRAW is not a RAW format because you say so? Canon says it is a RAW format. Again a RAW format is whatever format the manufacturer wants to use to maintain all the necessary data from the sensor.

I should have guessed you don't understand latin phrase, sorry for that. But no, stricto sensu, sRAW is not a RAW format because it has been democaised. Once democaised, some information from the sensor are lost. But who cares about wording?

So the process of direct conversion to RGB often result in unexpected results, like this CR2 image from my Canon 6D with a 3rd party RAW converter that doesn't know the 6D exists.

It seems you have no idea of what the CR2 format is, and how it differs for 6D compared to previous Canon cameras. There are many differences that can explain a RAW converter that doesn't know the 6D exists fails to convert a 6D image.

For example, since Canon 50D and digic IV, CFA RAW data are encoded in 4 components into the CR2 files. The 6D (and the 1Dx) use only 2 components. Tricky for a RAW converter, isn't it? This has nothing to do with sYCC.

No, it is an example of how the CR2 format hasn't been reverse engineered. Each camera that comes out, 3rd party RAW converters have to go in and look for what data that they can find that matches their concept of what RAW data should look like. And then force that round data into a square hole.

Sorry, but if you 3rd party RAW converter was not able do decode your 6D RAW file, it was not because it was encoded in sYCC. You should now know that it contains RGGB CFA data. By the way, you underestimate a lot the power of the reverse engineering.

Another flaw in this attempted direct conversion to RGB is that it uses the HSB/HSV color space instead of the HSL color space used by Canon.

Once again, you don't understand what you're talking about. HSL is used in Canon picture style editor. It has nothing to do with demosaicing.

Any time you demosaic it has to be done into a color space. And this is just another clue that Canon isn't simply using RGB to encode the data in the CR2 file. 3rd party RAW converters demosaic using the assumption that the data is in an HSB color space like the CRW and NEF formats use. It's clear from the Canon Picture Styles that Canon is using the HSL color space in camera (Picture Styles affect in camera JPG processing). Canon writing the RAW data into the HSL color space would explain why Canon is so much more efficient in moving RAW data.

Writing a lot a time the same wrong assertion won't make it true. Hopefully, 3rd party RAW converters don't use the assumption that the CR2 data are in HSL color space. Otherwise, they wouldn't be able to provide any image.

So what does all this actually mean. In my opinion the Canon CR2 file has been incorrectly reverse engineered by 3rd party RAW converters. This incorrect reverse engineering has only resulted in 12 bits of usable data per pixel and not the full 14 bits. And it is this that actually explains why testing sites that use 3rd party RAW converters show that Canon's per pixel dynamic range has remained unchanged in the last 10 years and not that the 2003 Digital Rebel and the Canon 1D X have the same per pixel dynamic range.

I'm really disappointed. I expected strong evidences, solid technical arguments. But no, it was only blabla and technical words ans concepts not understood by a Canon fanboy.

Ditto, except what you be called a DxOMark fanboy?

Did I wrote somewhere that DxO is good or bad?

At least I do not bash DxOMark when I don't like their results about DR and use their measures when I agree with them that more than 20Mp is useless: http://www.dpreview.com/forums/post/53280449

By the way. I'm very happy with my Canon cameras even if they have less DR than other brands.

Maybe that's because they really don't.

Post (hide subjects) Posted by
(unknown member)
Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow