Re: Shooting RAW vs RAW and JPG
- From: floyd@xxxxxxxxxx (Floyd L. Davidson)
- Date: Thu, 08 Nov 2007 22:45:31 -0900
Hmmmm... <nomail@xxxxxxxxxx> wrote:
Film has much more exposure latitude and dynamic range than
any digital camera will ever have (at least for now).
Digital surpassed film in dynamic range some time back.
(Exposure latitude is of course just a side effect of
dynamic range.)
Using RAW is one way of
retaining some of that dynamic range that the camera will throw away in its more
simple (faster) RAW to JPG conversion.
Cameras do not use a "more simple (faster)" conversion, so
that is not generally a problem.
The problem is that it is fixed, and without the raw
data set it cannot be done again with different
parameters. With the RAW file, the complete data set is
available and each shot can be converted with different
parameters if that is beneficial.
....
Now, high setting Fine in JPG with a larger image is 8 bits in my 10 MP
camera. RAW high quality Fine, large image is 12 bits. How would someone
get more bits per pixel then 12? I saw a mention of possible more but I
didn't have time to read the article to early this morning and now I cant
find it.
Cameras can have RAW file data in 10-bit, 12-bit, and 14-bit formats (so far).
When it is imported/converted into your RAW capable editing software, the
missing bits are padded out by null data (0's).
Bit sizes are *not* "padded out" with zeros.
You can't save only 12-bits of
information in a data-storage format that requires all data being in 8, 16, 32,
or 64 bits. You can discard 4 bits from that 12-bits of data to get an 8-bit
image, or pad it out with null bits to fit into the 16-bit format.
That is *not* what is happening. The raw data typically
is 12 bits per pixel from the sensor. The sensor has a
Bayer filter in front of it, and to get an image file
each pixel in the image must be generated, using
multiple pixels from the sensor data. The image format
can use a different number of bits per pixel than the
original. It is true that information is lost when a
lower bit depth is used, but it is *not* something as
simple as discarding 4 bits of the original 12 per
pixel. (If all of the adjacent sensor pixels provide
information for each resulting pixel in the output image
format there are at least 9 sensor bytes of 12 bits that
affect each pixel, whether it is 8 or 16 bit depth, in
the output image format.
Plus an "8-bit depth" file actually keeps 24 bits (one 8
bit byte for each of the Red, Green and Blue channels)
per pixel, which means there are actually twice as many
bits per pixel if nothing else is done. (That would,
for example, be true of a PPM or TIF formatted image.
With JPEG there is also significant compression, which
is the reason a smaller file results.)
Lets summarize parts of that to be more clear. In the
sensor data each pixel is described by 12 bits of data.
But in the output image file as many as 9 sensor locations
might be used to generate the data for a single pixel.
Hence 108 data bits might go into the generation of a
single pixel. And that pixel is described in the output
file by three channels, each with the 8 bit or 16 bit
depth. Hence for an 8 bit file that would be 24 bits total
per pixel, and with a 16 bit depth that would be 48 bits
per pixel (obviously both are significantly less than the
108 bits of data used to generate the information).
Here are some figures that demonstrate some of this. I
have a Nikon NEF format file, d2x_8521.nef, which is
19,799,848 bytes in size. Using /dcraw/, with the -e
option I can extract a thumbnail JPEG image from that
file, which is 1,070,369 bytes in size. Hence the
actual sensor data is something less than 18,729,479
bytes (it is less than that by the amount of EXIF data
and formatting cruft, but we can't tell exactly what that
is...).
If I then use /dcraw/ to produce an 8 bit PPM file, the
size is 37,100,465 bytes. It happens that we know the
image is 4312 x 2868 pixels in size, or 12,366,816
pixels. And with three channels of 8 bit bytes per
pixel, that would be 37,100,448 bytes. So there are
only a handfull of overhead bytes in the file produced.
If /dcraw/ is used to produce a 16 bit PPM file, the
size is 74,200,915.
Even though
those null bits are all 0's (zeros), they will still show up as a larger
file-size.
They won't be all zeros.
If what you are saying were true, the 16 bit PPM file
that I generated above would have every other byte set
equal to 0, but instead there are indeed bytes that
express the full range of 16 bits.
There are also various forms of compressed RAW data that do not do
this (just like the original smaller 12 bit file right from the camera). But
they require software capable of reading them. More often RAW data is converted
into the larger TIF or PNG (8 or 16 bit) file formats which are more
cross-platform compatible and able to be read by more programs.
I don't understand what that is saying...
I'm not a strong advocate of RAW, only using it when absolutely necessary. And
only then when the camera I am using has proven itself to not have a very good
RAW to JPG conversion internally (only one of my cameras benefits greatly from
using RAW more often because of this). In the cases of weddings where you are
dealing with subjects dressed in white and black in often dimly lit surroundings
to full sunlight outside of the buildings, the extra dynamic range available in
the RAW files can help compensate for the limitations of digital cameras--a
technology that cannot easily capture those subtle differences of black cloth in
shadows and white folds of a dress in sunlight. It has its uses.
And since it does better than the average film at that,
that *is* one of the uses... :-)
Especially if
you are not well verse in what your camera can and cannot do, and you need some
backup insurance. If you are well experienced with your particular camera,
photography in general, and your camera's RAW to JPG methods are exceptional
(many new ones are) then you may not even need RAW and still be able to obtain
images just as well from the JPG files.
Only you will know your own limitations and the limitations of your equipment,
and what needs to be done to get the best out of both.
--
Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
Ukpeagvik (Barrow, Alaska) floyd@xxxxxxxxxx
.
- References:
- Shooting RAW vs RAW and JPG
- From: Not4wood
- Re: Shooting RAW vs RAW and JPG
- From: Hmmmm . . .
- Shooting RAW vs RAW and JPG
- Prev by Date: Re: Point & shoots, no improvement as long as sensors stay SMALL
- Next by Date: Re: Point & shoots, no improvement as long as sensors stay SMALL
- Previous by thread: Re: Shooting RAW vs RAW and JPG
- Next by thread: Re: Shooting RAW vs RAW and JPG
- Index(es):
Relevant Pages
|
