
What does an unprocessed RAW file look like? - snailletters
https://petapixel.com/2019/07/15/what-does-an-unprocessed-raw-file-look-like/
======
arriu
If you want to extract the actual raw data, dcraw doesn't really advertise the
way to do it. Many of the options for extracting the data still apply some
processing/conversion to the underlying data.

It is a pretty big mess actually. Each manufacturer has different constants
that need to be applied to the data, so the raw data from one device is not
comparable to another. Convincing dcraw that you actually want the unaltered
data is not straight forward.

Anyways, if you really do want to see the raw image, there are a few
undocumented flags you can use.

> dcraw -E -4 -T *.CR2

This will give you an unprocessed 16-bit tiff file containing the "raw" data.

What is interesting is that some camera sensors capture data slightly beyond
the image you are presented with. The camera will crop in and debayer the
image for you, as will your image editor.

See this thread for hilarious lengths people go to in order to get unaltered
data from their sensors (monochorme converting a dslr):

[https://stargazerslounge.com/topic/166334-debayering-a-
dslrs...](https://stargazerslounge.com/topic/166334-debayering-a-dslrs-bayer-
matrix/page/94/)

~~~
bufferoverflow
That thread is more about removing the physical filters from the DSLR sensors
- RGB, UV, infrared to achieve higher resolution and much higher sensitivity.

------
3JPLW
Really cool article. I'm left with just one question:

Why are the 16-bit RAW values so limited in their dynamic range? Wouldn't
sensor manufacturers want to have their pixels able to return values that
range the whole way from 0x0000 to 0xffff?

~~~
fake-name
Very few (if any) digital cameras have 16-bit ADCs.

Most cameras use 12 or 14 bit ADCs, so they only use 2^12 or 2^14 of the
available values.

Generally, the RAW files aren't actually 16 bit, but rather a packed structure
of the native ADC size. In this case, they're using 16-bit _intermediate
bitmaps_. They're not 16 bit from the RAW.

\------

Fujifilm actually has a few cameras with a sensor that can be put in 16-bit
mode, but IIRC it's not enabled in software.

~~~
buildbot
Essentially only very high end digital backs from hasselblad/phase one have 16
bit ADCs, but people disagree if it’s even required, the last two bits are
basically noise.

~~~
kurthr
If the noise is actually white, that may not be a bad thing for filtering.

~~~
tigershark
I don’t really think that it’s white noise, it’s mostly thermal noise and
“reading the sensor” noise (forgot the real name) that have very different
shape from white noise. If they were so easily filtered we’d have far superior
denoise effectiveness during raw processing.

~~~
dr_zoidberg
> “reading the sensor” noise

"dark current"?

------
dlivingston
The author notes that 'But, there is no such standard...[a]ll real-world RAW
processing programs have their own ideas of a basic default state to apply to
a fresh RAW file on load'.

While I can accept that there isn't a universal RAW -> RGB standard, it seems
strange to me that 'compute how this photo should appear' is left as an
exercise as a reader.

Photographers often view their work as a form of art, and artists are very
particular about even the smallest details of their work.

Why, then, would Nikon, Canon, and especially Leica, not have their own
definable standards of how to process RAW photos for their particular cameras?

~~~
tinus_hn
A RAW file is a description of the light captured by the sensor. What good
would such a standard do? The RAW file is not supposed to be a finished work
of art, it’s designed to be processed.

~~~
theoh
Interestingly, some major photo competitions require 'original' RAW files to
be submitted along with processed jpegs. The idea is that they can check that
the image hasn't been modified in a way that breaks the rules.

Of course, software people know that it would be tedious but technically
straightforward to concoct a fake RAW file from another 'raw' format such as a
PPM image. The stakes in these competitions can be quite high so it's a bit
disconcerting that they rely on a presumption that converting RAW files to
editable images is a one-way process.

~~~
jacobush
No - it's not straightforward. How the light strikes, sensor imperfections,
patterns unique to each camera body even, thermal noise. It's very very hard
actually. It's one thing to doctor a finished image - it's another, in a
forensic level really, to doctor a RAW file. You can make one which on its own
is syntactically correct but which does not show all the telltale signs of
being shot in actual hardware, no patterns or imperfections etc. This is
trivial.

Next level is to make it look plausible on its own, with plausible
imperfections. This is a bit more involved and tedious.

The really hard part is to make it look like it came from the exact same
individual purported camera body the photographer allegedly used. This is
really hard.

An analogy would perhaps be taking a picture of a room:

Now, build another room that would make the same picture. Make sure everything
in the room is plausible yet renders exactly the same picture as the first
room. (The room is the RAW file.)

Edit: (I'm not saying all the competitions have the time and know how to
verify a RAW file.)

~~~
theoh
The scenario I'm talking about is not synthesising a RAW file from scratch,
but being able to freely edit it and save the result back into a RAW file that
looks "original". I don't think you've made any statements that indicate that
doing that would be complex.

Again, this is not about faking a RAW file from scratch, just being able to
edit it in place.

~~~
jacobush
One potential complication just occurred to me. If, (IFF!) each sensor site
has a somewhat unique non-linearity in any way, you can't just go around in
the image and change "pixels". You have to adjust them in a way that would not
change the patterns normal to that camera for that sensor site _and_ for
neighboring sensor sites which could have been affected by the same light.

------
Causality1
Something that's fascinating to me is that at 1:1 display size, the output of
modern cameras doesn't look that much better than the pictures out of old
0.3Mpixel still cameras of nearly twenty years ago. The dynamic range is
better and the colors are more vibrant, and the noise floor is lower for dark
scenes, but on the whole it still looks pretty crappy at full resolution. Why
is that? Could we fix it by using larger CCD/CMOS sensor pixels and sticking
to lower total pixel counts?

~~~
pvg
What images are you comparing? 20 year old digital cameras were around a
Mpixel. A modern camera with a decent lense produces much better images. In
both cases you'd have to do some work to make sure the thing you're blowing up
is exactly in focus.

------
JoshMcguigan
This was really neat, but I wish the author went into similar detail for the
auto white balance step.

~~~
vortico
White-balancing is a function

    
    
        f(R, G, B, T_from, T_to) -> (R, G, B)
    

which relies on the model of blackbody radiation and a model of the wavelength
distribution definitions behind the (R, G, B) values, i.e. the particular
color space you're working in. When working with a manufacturer's RAW format,

Auto white-balancing is finding `T_to` so that the color values are "most
balanced". It is up to the manufacturer how this is decided (and might be
proprietary secret sauce). Custom white-balancing is taking a known white or
grayscale object and finding `T_to` which would yield something close to (1,
1, 1) for pixels of that object.

~~~
vortico
I think I accidentally erased a sentence in an edit...

When working with a manufacturer's RAW format, there is a defined way to get
the values (R, G, B, T_from) as a result of demosaicing. For example, in the
author's photo post-demosaicing, the manufacturer calibrates the final data to
obtain (I'm completely making this up) T_from = 2700K. Then using that
information, you can correctly adjust the temperature to any other temperature
using `f` above.

------
cfstras
Try [https://github.com/anuejn/batic](https://github.com/anuejn/batic) \- a
shadertoy-like experiment where you can to implement a shader to convert the
bayer-pattern.

------
ggm
This reminded me of the autochrome process. I believe they did something with
coloured starch grains and lamp black.

------
bradknowles
A raw file? Well, it's really more a lump of metal, until you start putting
some teeth on it and you're ready for the tempering process.

/s

