How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8 Has

The manual does not state; not even the 'specifications' page at the end. I
have seen one reference on the web to it being 8 bits per channel: 24 bits
per pixel. This seems to be quite low; is it normal for a modern camera?
I use SilkyPix to read the raw files but it does not tell me the bit depth
of the images.

Advertisements

"Davy" <> wrote in message
news:...
> The manual does not state; not even the 'specifications' page at the end.
> I
> have seen one reference on the web to it being 8 bits per channel: 24 bits
> per pixel. This seems to be quite low; is it normal for a modern camera?
> I use SilkyPix to read the raw files but it does not tell me the bit depth
> of the images.
>
> thanks, Davy
>
>

Most all digital cameras do 24 bit images. That is a standard RGB image.

Advertisements

On Tue, 02 Oct 2007 20:57:08 +0100, Davy wrote:
> The manual does not state; not even the 'specifications' page at the end. I
> have seen one reference on the web to it being 8 bits per channel: 24 bits
> per pixel. This seems to be quite low; is it normal for a modern camera?
> I use SilkyPix to read the raw files but it does not tell me the bit depth
> of the images.
>
> thanks, Davy

When saved to a jpeg file, you get 8 bits per channel. AFAIK - most raw
capable cameras do raw files at 12 bits per channel - don't know, but some
may be capable of more. Have you tried looking at the exif data in your
raw file? It may be in there somewhere.

"Davy" <> wrote:
>The manual does not state; not even the 'specifications' page at the end. I
>have seen one reference on the web to it being 8 bits per channel: 24 bits
>per pixel. This seems to be quite low; is it normal for a modern camera?
>I use SilkyPix to read the raw files but it does not tell me the bit depth
>of the images.
>
>thanks, Davy

I couldn't find anything sufficiently authoritative to
be postive; but almost certainly the raw data file
produced by the FZ8 is in a 12 bit _linear_ format.

A "RAW converter", such as SilkyPix, generally outputs a
JPEG format image (though others are usually possible),
which is an 8 bit _gamma_ _corrected_ format. The
difference between "linear" and "gamma corrected" is
significant when comparing bit depth.

For example, in the brightest fstop (zone) of an image a
12 bit linear file can save as many 2048 different
values. Your eyes of course cannot see a variation of
1/2000 of an fstop! So JPEG compresses that down to
saving only 69 different levels (which is still finer
than our eyes can detect). In the second brightest
zone, a linear raw file saves half as many, or 1024
values. In a gamma corrected JPEG file there are 50
levels.

The effect is that *if* the JPEG format has the correct
white balance and correct exposure, it will *look* exactly
the same as an image with twice as many bits per channel!
The problem is that if anything is not exactly right, any
attempt at adjusting brightness/contrast to get it right
is almost certainly going to visibly degrade the image.

You camera can produce either JPEG files or RAW files.
Which you choose depends on what you want to do. At the
extremes, most people who shoot snapshots of family,
pets, and neighbors couldn't care less (and can't tell)
when a snapshot is plus or minus 1 fstop of correct
exposure. The last thing they want to do is try fussing
with a photo editor to get every single picture just
perfect.

They definitely want to shoot JPEG. It's faster, it's
easier, they get more pictures, and it's perfect for
them.

At the other end of the spectrum are people who want to
produce art with a camera, and just simply *must* have
control of ever possible detail in every image. They can
do far more adjusting and fussing with a RAW file than
with a JPEG image. RAW is perfect for them.

In between those extremes are where most people live.
The tilt is probably decidedly towards shooting JPEG
only for most people who purchase a Panasonic FZ8, and
that is what it is "tuned" for. But it does provide the
tools and you *can* do RAW processing any time you
choose!

"Davy" <> wrote in message
news:...
> The manual does not state; not even the 'specifications' page at the end.
I
> have seen one reference on the web to it being 8 bits per channel: 24 bits
> per pixel. This seems to be quite low; is it normal for a modern camera?
> I use SilkyPix to read the raw files but it does not tell me the bit depth
> of the images.
>
Another thought on my question above. It is a 7M pixel camera. If the
camera produces 8 bits per channel, there are three channels and there are 8
bits in a byte - so it would require 3 bytes to record one pixel. So a 7M
pixel camera should produce raw files 21 Mbytes in size. In fact the raw
files are half this - only 11M bytes.

Davy wrote:
> "Davy" <> wrote in message
> news:...
>> The manual does not state; not even the 'specifications' page at the
>> end. I have seen one reference on the web to it being 8 bits per
>> channel: 24 bits per pixel. This seems to be quite low; is it
>> normal for a modern camera? I use SilkyPix to read the raw files but
>> it does not tell me the bit depth of the images.
>>
> Another thought on my question above. It is a 7M pixel camera. If
> the camera produces 8 bits per channel, there are three channels and
> there are 8 bits in a byte - so it would require 3 bytes to record
> one pixel. So a 7M pixel camera should produce raw files 21 Mbytes
> in size. In fact the raw files are half this - only 11M bytes.
>
> What's wrong with my arithmetic?
>
> Davy

"Davy" <> wrote:
>"Davy" <> wrote in message
>news:...
>> The manual does not state; not even the 'specifications' page at the end.
>I
>> have seen one reference on the web to it being 8 bits per channel: 24 bits
>> per pixel. This seems to be quite low; is it normal for a modern camera?
>> I use SilkyPix to read the raw files but it does not tell me the bit depth
>> of the images.
>>
>Another thought on my question above. It is a 7M pixel camera. If the
>camera produces 8 bits per channel, there are three channels and there are 8
>bits in a byte - so it would require 3 bytes to record one pixel. So a 7M
>pixel camera should produce raw files 21 Mbytes in size. In fact the raw
>files are half this - only 11M bytes.
>
>What's wrong with my arithmetic?

7Mp per image, times 12 bits per pixel, divided by 8
bits per byte, is about 10.5 Mbytes per image.

In addition to the pixel data there would likely also be
significant data about the camera settings, and perhaps
a small JPEG thumbnail image too.

Note that the raw image data is 12 bits per pixel and
there is only a single channel. The raw data has a
Bayer color pattern. Each pixel is one color only, in a
RGGB pattern. Part of converting from raw data to an
image format is using a group of pixels to determine
what each pixel's color would be.

When it is converted to another format it gets changed
to an RGB format, where there are three channels per
pixel. If you have an 11 Mb raw file... try converting
it to 16 bit TIFF or PPM format! That file will end up
being 42Mb in size!

Something you might or might not be aware of is that
every image has EXIF data included with the pixel data.
There are various programs that let you see that data,
and it can be very interesting. If you have perl on
your machine, try finding /exiftool/, which is a set
of perl scripts that can show/edit the data.

Lacking that, if you can put one raw image file up on
the web someplace where it can be accessed, I and
probably many others would be happy to download it and
dump the EXIF data from it, and then post the data with
a commentary on what it means to you.

"Floyd L. Davidson" <> wrote in message
news:...
if you can put one raw image file up on
> the web someplace where it can be accessed, I and
> probably many others would be happy to download it and
> dump the EXIF data from it, and then post the data with
> a commentary on what it means to you.

Regarding your:
>Note that the raw image data is 12 bits per pixel and
>there is only a single channel. The raw data has a
>Bayer color pattern. Each pixel is one color only, in a
>RGGB pattern. Part of converting from raw data to an
>image format is using a group of pixels to determine
>what each pixel's color would be.

I seem to have bought a really crappy camera; only 12 bpp and doesn't even
record what the colour of the pixels are !!
>When it is converted to another format it gets changed
>to an RGB format, where there are three channels per
>pixel. If you have an 11 Mb raw file... try converting
>it to 16 bit TIFF or PPM format! That file will end up
>being 42Mb in size!
You're predictions are exactly right. TIFF (8) files are 20Mb and TIFF16
files 40Mb.

On Wed, 03 Oct 2007 09:10:08 +0100, Davy wrote:
>
> "Davy" <> wrote in message
> news:...
>> The manual does not state; not even the 'specifications' page at the end.
> I
>> have seen one reference on the web to it being 8 bits per channel: 24 bits
>> per pixel. This seems to be quite low; is it normal for a modern camera?
>> I use SilkyPix to read the raw files but it does not tell me the bit depth
>> of the images.
>>
> Another thought on my question above. It is a 7M pixel camera. If the
> camera produces 8 bits per channel, there are three channels and there are 8
> bits in a byte - so it would require 3 bytes to record one pixel. So a 7M
> pixel camera should produce raw files 21 Mbytes in size. In fact the raw
> files are half this - only 11M bytes.
>
> What's wrong with my arithmetic?
>
> Davy

Actually, it's raw data is probably 12 bits per channel but, as I
understand it, each physical pixel is one color, so it's acutally 12 bits
or 1.5 bytes per pixel, so 7mp should yield about 10.5 MB - right on
target. The information is 'demosaiced' to create a usable image - i.e.
the data from the r,g,b pixels surrounding each location are combined to
come up with the r,g,b channels for each pixel. I think the widipedia
article on raw digital camer formats does a good job of explaining it.

On Wed, 03 Oct 2007 14:12:30 +0100, Davy wrote:
>
> "Floyd L. Davidson" <> wrote in message
> news:...
> if you can put one raw image file up on
>> the web someplace where it can be accessed, I and
>> probably many others would be happy to download it and
>> dump the EXIF data from it, and then post the data with
>> a commentary on what it means to you.
>
> Floyd, thanks for the offer, the file is at:
>
> http://www.callnetuk.com/home/davystokes/photos.htm - click on the hyperlink
> at the top of the page
>
> Regarding your:
>
>>Note that the raw image data is 12 bits per pixel and
>>there is only a single channel. The raw data has a
>>Bayer color pattern. Each pixel is one color only, in a
>>RGGB pattern. Part of converting from raw data to an
>>image format is using a group of pixels to determine
>>what each pixel's color would be.
>
> I seem to have bought a really crappy camera; only 12 bpp and doesn't even
> record what the colour of the pixels are !!
>
>>When it is converted to another format it gets changed
>>to an RGB format, where there are three channels per
>>pixel. If you have an 11 Mb raw file... try converting
>>it to 16 bit TIFF or PPM format! That file will end up
>>being 42Mb in size!
> You're predictions are exactly right. TIFF (8) files are 20Mb and TIFF16
> files 40Mb.
>
> cheers
>
> Davy

Nice pictures. If you typically do that sort of
work with an FZ8... have you ever considered spending
some real money and getting a real camera??? ;-)

It does appear that a top notch camera would have
benefits for you.

Anyway, the first two things I noticed, were that there
is no thumbnail image embedded in the RAW file, and that
there is a significant amount *less* information than in
a JPG image from an FZ8 that I downloaded somewhere.
Not just stuff that relates only to in camera processing
either. (The JPG images you have are typical of
anything processed with an editor in that they have been
stripped of almost everything the camera had, and have
almost no useful other than the image size.)

Here is the EXIF data dumped from a JPEG image
downloaded somewhere. There are more than twice as many
items in this list compared to the above. I'm
suspecting this is from a later version of the camera,
but it could be that the JPEG formatted file simply has
more.

thanks for the kind words. Would a 'real' camera be one with
interchangeable lenses? I did all that with film cameras in the 80s and 90s
and don't think I can go back to carry camera tote bags full of
interchangeable lenses!

Also thanks for reading the exif data for my photo; pity it did not contain
the information needed. But I think that since the file sizes are
commensurate with the sensor providing linear 12 bit pixel data then I have
confidence in that figure.

This whole post has got a lot more technical than I expected. I changed to
using raw just two weeks ago so the learning curve has been very steep - but
worth it.

My motive for asking how many bits per pixel my camera generates was that I
was trying to decide what bit depth my workflow should be. So for instance
if my camera is generating 12 bit pixels, then 8 bit per channel software
should be adaquate ?? Archiving the files as ordinary TIFF (8 bit) should
be adaquate?

About a week ago I asked for recommendations for software that would support
a Windows 2000 based workflow. I did not get any replies but since then I
have developed the following workflow. Does it seem sensible?

On Wed, 03 Oct 2007 09:18:49 -0800, (Floyd L. Davidson) wrote:
>Nice pictures. If you typically do that sort of
>work with an FZ8... have you ever considered spending
>some real money and getting a real camera??? ;-)
>

Seems to me he already has a real camera. If you typically do this kind of
usenet posting have you ever considered getting a real brain? Or at least some
real photography experience.

"Davy" <> wrote:
>Floyd,
>
>thanks for the kind words. Would a 'real' camera be one with
>interchangeable lenses? I did all that with film cameras in the 80s and 90s
>and don't think I can go back to carry camera tote bags full of
>interchangeable lenses!

Actually there are loads of "real" cameras that are not
DSLR's. I'm not a camera store clerk though (and some
folks who post here appparently are), and can't really
provide much perspective on good Point & Shoot cameras
(or for that matter on DSLR's either).
>Also thanks for reading the exif data for my photo; pity it did not contain
>the information needed. But I think that since the file sizes are
>commensurate with the sensor providing linear 12 bit pixel data then I have
>confidence in that figure.
>
>This whole post has got a lot more technical than I expected. I changed to
>using raw just two weeks ago so the learning curve has been very steep - but
>worth it.

Heh, there is *no* end to it either, or so it seems!
With film is was simply all of your time and all of your
money. It doesn't take much money these days, but it is
still time consuming.
>My motive for asking how many bits per pixel my camera generates was that I
>was trying to decide what bit depth my workflow should be. So for instance
>if my camera is generating 12 bit pixels, then 8 bit per channel software
>should be adaquate ??

Here we had this nice pleasant thread going, and now
you've gone and opened the Pandora's Box. No matter
what is said in response to that question, somebody will
be adamant that it is wrong; both sides will have
logical arguments too...

For _most_ things, editing with an 8 bit per channel
editor is sufficient. For some it is not. If you tend
to dicker with gradients, 8 bits will not be enough.
For example, you seem to like landscapes, and might play
with the the light variations in the sky. If you try
adjusting contrast ranges in broad expanses of sky using
an 8 bit editor, you'll get banding if you go too far.
With a 16 bit editor the gradients can be expanded to
virtually any reasonable degree without posterization.

Hence you probably want to use a 16 bit work flow if it
is easy (all other things being equal, choose 16 bit
software over 8 bit software). If you don't like the 16
bit software, don't use it all the time but do have it
available for when it makes a difference.

(I work on a Linux platform, and use The GIMP, which is
8 bit, for editing almost everything. I do have a
significantly less suitable editor called /cinepaint/,
just so that I can do some things in 16 bits if needed.)
>Archiving the files as ordinary TIFF (8 bit) should
>be adaquate?

I would not do that under any circumstance. *Never*
delete the RAW file for any image that is useful.

Worse yet, you probably want at least two copies of
every RAW file, and if possible have them on two
different computers located in two different physical
locations.

If you want to convert it to an image file and archive
that, it definitely should be 16 bits per channel. In
fact it makes some sense to do the initial conversion
from the RAW data to a 16 bit format, and then archive
both. The 16 bit format would then be the starting point
for whatever editing is done. You could easily end up
with multiple 16 bit conversions, each different.

A better way, however, is to use a conversion program
which will save it's entire configuration for each
image. Then, rather than archiving individual huge 16
bit image files, only a very small configuration file is
saved, and that is used to regenerate that 16 bit image
file at any time.
>About a week ago I asked for recommendations for software that would support
>a Windows 2000 based workflow. I did not get any replies but since then I
>have developed the following workflow. Does it seem sensible?

I use Linux, so I can't really be of much use in regard
to a Windows workflow.

However... Given that your camera produces a RAW file that
has no embedded JPEG image, and will only produce either RAW
or JPEG, the way I would want to deal with RAW would be something
like this:

1) Download RAW files to the computer.

A. Use a batch process to generate a "preview"
JPEG image using default settings. These
do not need to be high quality conversions,
but should be full sized and "good enough".

A. Individually do a high quality conversion
to a suitable intermediate image format.

1. This file actually never needs to be
saved to disk at all, it it can be
fed directly to an editor, while the
configuration file is saved. That
would be typical operation if the
conversion is a plugin module for the
editor of choice.

2. Save and archive the configuration
file which allows this conversion to
be repeated again.

B. Edit as desired, saving either intermediate
files or configuration files, as needed.

C. Archive work files as needed.

3) Use scripted batch processing to apply whatever
"standard" decorations you choose to for your
work. For example, a signature/copyright notice,
borders, or whatever...

I want to look at each image in full screen size to make
decisions on actually deleting.
> Right click unwanted images, set delete mark, use file/delete marked
>when finished
> Tweak
> · Use Siklypix defaults - they seem to be very good
> . Use 'camera setting' for automatic adjust of
>colour balance

Color balance is quirky. Often a camera does pretty
good, so using that as your default is probably good.
Just be aware that now and then the camera will be
totally wrong, or that the software might give a better
balance, or that neither will and you will need to
manually set it.
> · Max sharpen on drop down menu (is quite
>conservative)

Set sharpening to zero. Sharpening depends on the
display, and should be the last thing done before
printing or uploading to a webpage. It is individually
done per _useage_.
> Reserve mark those images requiring archive quality. - Develop RAW to
>TIFF (8 with Exif) using AdobeRGB colour space
>In Photoshop Elements 2
>· Read TIFFs
>. crop
>· using levels tool adjust max light and dark and mid
>ones - but not discarding any data at extremes
>· adjust colour balance - rarely needed cos Silkypix does it
>well

If color balance needs adjustment, I'd go all the way
back to the RAW to image conversion, and do it there
(basically, start over).
>· if really needed then enhance saturation
>· touch up/remove unwanted items, blemishes, smooth skin,
>etc
>· add more sharpening if Silkypix did not do enough
>· Reduce noise

Do noise reduction *before* you do anything to sharpen
it. That includes applying Unsharp Mask techniques too.
>· Convert to web, print etc
>
>Delete RAW and the two other files created by the camera for each image.

Don't do that. Archive the RAW files. Write them to
DVD's or buy a lot of really big disks.

For example you can get SATA to USB 2.0 adapters, and a
couple of 500 Gb disk drives, all relatively for a low
price. Write *everything* off to two different disks.

Then disconnect the disks between operations, and leave
them sitting, unpowered, on the shelf. If one of those
disks ever does die, *immediately* get another one and
make a second copy of everything.
>In the above workflow I have not found a need for using DNG from the Adobe
>DNG generator. Does the workflow seem reasonable?

On Thu, 04 Oct 2007 18:20:49 +0100, Davy wrote:
> Floyd,
>
> thanks for the kind words. Would a 'real' camera be one with
> interchangeable lenses? I did all that with film cameras in the 80s and 90s
> and don't think I can go back to carry camera tote bags full of
> interchangeable lenses!
>
> Also thanks for reading the exif data for my photo; pity it did not contain
> the information needed. But I think that since the file sizes are
> commensurate with the sensor providing linear 12 bit pixel data then I have
> confidence in that figure.
>
> This whole post has got a lot more technical than I expected. I changed to
> using raw just two weeks ago so the learning curve has been very steep - but
> worth it.
>
> My motive for asking how many bits per pixel my camera generates was that I
> was trying to decide what bit depth my workflow should be. So for instance
> if my camera is generating 12 bit pixels, then 8 bit per channel software
> should be adaquate ?? Archiving the files as ordinary TIFF (8 bit) should
> be adaquate?

I'm fairly new to this process too, but I archive my raw files. If
anything happens to the processed images, I can always go back to square
one. I backup all images to at least two different computers (the laptop I
carry on trips for the purpose of viewing images while we're gone, any my
big desktop where I do most processing), an external hard drive and
another copy to CD/DVD.
>
> About a week ago I asked for recommendations for software that would support
> a Windows 2000 based workflow. I did not get any replies but since then I
> have developed the following workflow. Does it seem sensible?

On Oct 3, 6:05 am, (Floyd L. Davidson) wrote:
> ... If you have perl on
> your machine, try finding /exiftool/, which is a set
> of perl scripts that can show/edit the data.
> ...

I think there's a version of ExifTool, available from the
same website, that doesn't require Perl. I've used it
successfully but I'm not certain it doesn't require Perl
because I have Perl on all my machines.

Floyd,
thanks for taking the time for such a very full response. There is a lot to
chew on there so I will give it a go but don't expect an instant answer.
As per your recommendations:
The Panasonic DMC-FZ8 produces a 3Mb jpg in parallel with raw files. So I
will browse these cos they are much faster to view than raw files. I am in
the process of writing a scripted batch program to delete raw files which
were viewed as jpgs and deleted
I have ordered an external hard drive
I have obtained a data fire safe to keep it in

Off tomorrow to Exeter to see the old town, the cathedral and historic
harbour - very good photo opportunities. Will be able to try out the new
workflow on the results.

thanks, Davy

"Floyd L. Davidson" <> wrote in message
news:...
> "Davy" <> wrote:
> >Floyd,
> >
> >thanks for the kind words. Would a 'real' camera be one with
> >interchangeable lenses? I did all that with film cameras in the 80s and
90s
> >and don't think I can go back to carry camera tote bags full of
> >interchangeable lenses!
>
>
>
> Actually there are loads of "real" cameras that are not
> DSLR's. I'm not a camera store clerk though (and some
> folks who post here appparently are), and can't really
> provide much perspective on good Point & Shoot cameras
> (or for that matter on DSLR's either).
>
> >Also thanks for reading the exif data for my photo; pity it did not
contain
> >the information needed. But I think that since the file sizes are
> >commensurate with the sensor providing linear 12 bit pixel data then I
have
> >confidence in that figure.
> >
> >This whole post has got a lot more technical than I expected. I changed
to
> >using raw just two weeks ago so the learning curve has been very steep -
but
> >worth it.
>
> Heh, there is *no* end to it either, or so it seems!
> With film is was simply all of your time and all of your
> money. It doesn't take much money these days, but it is
> still time consuming.
>
> >My motive for asking how many bits per pixel my camera generates was that
I
> >was trying to decide what bit depth my workflow should be. So for
instance
> >if my camera is generating 12 bit pixels, then 8 bit per channel software
> >should be adaquate ??
>
> Here we had this nice pleasant thread going, and now
> you've gone and opened the Pandora's Box. No matter
> what is said in response to that question, somebody will
> be adamant that it is wrong; both sides will have
> logical arguments too...
>
> For _most_ things, editing with an 8 bit per channel
> editor is sufficient. For some it is not. If you tend
> to dicker with gradients, 8 bits will not be enough.
> For example, you seem to like landscapes, and might play
> with the the light variations in the sky. If you try
> adjusting contrast ranges in broad expanses of sky using
> an 8 bit editor, you'll get banding if you go too far.
> With a 16 bit editor the gradients can be expanded to
> virtually any reasonable degree without posterization.
>
> Hence you probably want to use a 16 bit work flow if it
> is easy (all other things being equal, choose 16 bit
> software over 8 bit software). If you don't like the 16
> bit software, don't use it all the time but do have it
> available for when it makes a difference.
>
> (I work on a Linux platform, and use The GIMP, which is
> 8 bit, for editing almost everything. I do have a
> significantly less suitable editor called /cinepaint/,
> just so that I can do some things in 16 bits if needed.)
>
> >Archiving the files as ordinary TIFF (8 bit) should
> >be adaquate?
>
> I would not do that under any circumstance. *Never*
> delete the RAW file for any image that is useful.
>
> Worse yet, you probably want at least two copies of
> every RAW file, and if possible have them on two
> different computers located in two different physical
> locations.
>
> If you want to convert it to an image file and archive
> that, it definitely should be 16 bits per channel. In
> fact it makes some sense to do the initial conversion
> from the RAW data to a 16 bit format, and then archive
> both. The 16 bit format would then be the starting point
> for whatever editing is done. You could easily end up
> with multiple 16 bit conversions, each different.
>
> A better way, however, is to use a conversion program
> which will save it's entire configuration for each
> image. Then, rather than archiving individual huge 16
> bit image files, only a very small configuration file is
> saved, and that is used to regenerate that 16 bit image
> file at any time.
>
> >About a week ago I asked for recommendations for software that would
support
> >a Windows 2000 based workflow. I did not get any replies but since then
I
> >have developed the following workflow. Does it seem sensible?
>
> I use Linux, so I can't really be of much use in regard
> to a Windows workflow.
>
> However... Given that your camera produces a RAW file that
> has no embedded JPEG image, and will only produce either RAW
> or JPEG, the way I would want to deal with RAW would be something
> like this:
>
> 1) Download RAW files to the computer.
>
> A. Use a batch process to generate a "preview"
> JPEG image using default settings. These
> do not need to be high quality conversions,
> but should be full sized and "good enough".
>
> B. Review the JPEG's, deleting obvious culls.
>
> C. Using a scripted batch process (to avoid
> mistakes), delete any RAW file matching a
> deleted JPEG.
>
> D. Copy all RAW files to archive(s).
>
> E. Delete RAW files from Camera or memory card.
>
> 2) Again review the JPEG previews and process
> selected images.
>
> A. Individually do a high quality conversion
> to a suitable intermediate image format.
>
> 1. This file actually never needs to be
> saved to disk at all, it it can be
> fed directly to an editor, while the
> configuration file is saved. That
> would be typical operation if the
> conversion is a plugin module for the
> editor of choice.
>
> 2. Save and archive the configuration
> file which allows this conversion to
> be repeated again.
>
> B. Edit as desired, saving either intermediate
> files or configuration files, as needed.
>
> C. Archive work files as needed.
>
> 3) Use scripted batch processing to apply whatever
> "standard" decorations you choose to for your
> work. For example, a signature/copyright notice,
> borders, or whatever...
>
> 4) Archive final product files as needed.
>
> >In SilkyPix
> > Browse RAWs in thumbnail view with outline display showing
>
> I want to look at each image in full screen size to make
> decisions on actually deleting.
>
> > Right click unwanted images, set delete mark, use file/delete marked
> >when finished
> > Tweak
> > · Use Siklypix defaults - they seem to be very
good
> > . Use 'camera setting' for automatic adjust of
> >colour balance
>
> Color balance is quirky. Often a camera does pretty
> good, so using that as your default is probably good.
> Just be aware that now and then the camera will be
> totally wrong, or that the software might give a better
> balance, or that neither will and you will need to
> manually set it.
>
> > · Max sharpen on drop down menu (is quite
> >conservative)
>
> Set sharpening to zero. Sharpening depends on the
> display, and should be the last thing done before
> printing or uploading to a webpage. It is individually
> done per _useage_.
>
> > Reserve mark those images requiring archive quality. - Develop RAW to
> >TIFF (8 with Exif) using AdobeRGB colour space
> >In Photoshop Elements 2
> >· Read TIFFs
> >. crop
> >· using levels tool adjust max light and dark and mid
> >ones - but not discarding any data at extremes
> >· adjust colour balance - rarely needed cos Silkypix does
it
> >well
>
> If color balance needs adjustment, I'd go all the way
> back to the RAW to image conversion, and do it there
> (basically, start over).
>
> >· if really needed then enhance saturation
> >· touch up/remove unwanted items, blemishes, smooth skin,
> >etc
> >· add more sharpening if Silkypix did not do enough
> >· Reduce noise
>
> Do noise reduction *before* you do anything to sharpen
> it. That includes applying Unsharp Mask techniques too.
>
> >· Convert to web, print etc
> >
> >Delete RAW and the two other files created by the camera for each image.
>
> Don't do that. Archive the RAW files. Write them to
> DVD's or buy a lot of really big disks.
>
> For example you can get SATA to USB 2.0 adapters, and a
> couple of 500 Gb disk drives, all relatively for a low
> price. Write *everything* off to two different disks.
>
> Then disconnect the disks between operations, and leave
> them sitting, unpowered, on the shelf. If one of those
> disks ever does die, *immediately* get another one and
> make a second copy of everything.
>
> >In the above workflow I have not found a need for using DNG from the
Adobe
> >DNG generator. Does the workflow seem reasonable?
>
> I haven't got a clue as to why anyone would use DNG at this
> point.
>
> --
> Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
> Ukpeagvik (Barrow, Alaska)

Floyd,
thanks for taking the time for such a very full response. There is a lot to
chew on there so I will give it a go but don't expect an instant answer.
As per your recommendations:
- The Panasonic DMC-FZ8 produces a 1.7 Mb jpg in parallel with raw files. So
I
will browse these cos they are much faster to view than raw files.
- I have written a scripted batch program to delete raw files which
were viewed as jpgs and deleted
- I have ordered an external hard drive
- I have obtained a data fire safe to keep it in

Off tomorrow to Exeter to see the old town, the cathedral and historic
harbour - very good photo opportunities. Will be able to try out the new
workflow on the results.

thanks, Davy

"Floyd L. Davidson" <> wrote in message
news:...
> "Davy" <> wrote:
> >Floyd,
> >
> >thanks for the kind words. Would a 'real' camera be one with
> >interchangeable lenses? I did all that with film cameras in the 80s and
90s
> >and don't think I can go back to carry camera tote bags full of
> >interchangeable lenses!
>
>
>
> Actually there are loads of "real" cameras that are not
> DSLR's. I'm not a camera store clerk though (and some
> folks who post here appparently are), and can't really
> provide much perspective on good Point & Shoot cameras
> (or for that matter on DSLR's either).
>
> >Also thanks for reading the exif data for my photo; pity it did not
contain
> >the information needed. But I think that since the file sizes are
> >commensurate with the sensor providing linear 12 bit pixel data then I
have
> >confidence in that figure.
> >
> >This whole post has got a lot more technical than I expected. I changed
to
> >using raw just two weeks ago so the learning curve has been very steep -
but
> >worth it.
>
> Heh, there is *no* end to it either, or so it seems!
> With film is was simply all of your time and all of your
> money. It doesn't take much money these days, but it is
> still time consuming.
>
> >My motive for asking how many bits per pixel my camera generates was that
I
> >was trying to decide what bit depth my workflow should be. So for
instance
> >if my camera is generating 12 bit pixels, then 8 bit per channel software
> >should be adaquate ??
>
> Here we had this nice pleasant thread going, and now
> you've gone and opened the Pandora's Box. No matter
> what is said in response to that question, somebody will
> be adamant that it is wrong; both sides will have
> logical arguments too...
>
> For _most_ things, editing with an 8 bit per channel
> editor is sufficient. For some it is not. If you tend
> to dicker with gradients, 8 bits will not be enough.
> For example, you seem to like landscapes, and might play
> with the the light variations in the sky. If you try
> adjusting contrast ranges in broad expanses of sky using
> an 8 bit editor, you'll get banding if you go too far.
> With a 16 bit editor the gradients can be expanded to
> virtually any reasonable degree without posterization.
>
> Hence you probably want to use a 16 bit work flow if it
> is easy (all other things being equal, choose 16 bit
> software over 8 bit software). If you don't like the 16
> bit software, don't use it all the time but do have it
> available for when it makes a difference.
>
> (I work on a Linux platform, and use The GIMP, which is
> 8 bit, for editing almost everything. I do have a
> significantly less suitable editor called /cinepaint/,
> just so that I can do some things in 16 bits if needed.)
>
> >Archiving the files as ordinary TIFF (8 bit) should
> >be adaquate?
>
> I would not do that under any circumstance. *Never*
> delete the RAW file for any image that is useful.
>
> Worse yet, you probably want at least two copies of
> every RAW file, and if possible have them on two
> different computers located in two different physical
> locations.
>
> If you want to convert it to an image file and archive
> that, it definitely should be 16 bits per channel. In
> fact it makes some sense to do the initial conversion
> from the RAW data to a 16 bit format, and then archive
> both. The 16 bit format would then be the starting point
> for whatever editing is done. You could easily end up
> with multiple 16 bit conversions, each different.
>
> A better way, however, is to use a conversion program
> which will save it's entire configuration for each
> image. Then, rather than archiving individual huge 16
> bit image files, only a very small configuration file is
> saved, and that is used to regenerate that 16 bit image
> file at any time.
>
> >About a week ago I asked for recommendations for software that would
support
> >a Windows 2000 based workflow. I did not get any replies but since then
I
> >have developed the following workflow. Does it seem sensible?
>
> I use Linux, so I can't really be of much use in regard
> to a Windows workflow.
>
> However... Given that your camera produces a RAW file that
> has no embedded JPEG image, and will only produce either RAW
> or JPEG, the way I would want to deal with RAW would be something
> like this:
>
> 1) Download RAW files to the computer.
>
> A. Use a batch process to generate a "preview"
> JPEG image using default settings. These
> do not need to be high quality conversions,
> but should be full sized and "good enough".
>
> B. Review the JPEG's, deleting obvious culls.
>
> C. Using a scripted batch process (to avoid
> mistakes), delete any RAW file matching a
> deleted JPEG.
>
> D. Copy all RAW files to archive(s).
>
> E. Delete RAW files from Camera or memory card.
>
> 2) Again review the JPEG previews and process
> selected images.
>
> A. Individually do a high quality conversion
> to a suitable intermediate image format.
>
> 1. This file actually never needs to be
> saved to disk at all, it it can be
> fed directly to an editor, while the
> configuration file is saved. That
> would be typical operation if the
> conversion is a plugin module for the
> editor of choice.
>
> 2. Save and archive the configuration
> file which allows this conversion to
> be repeated again.
>
> B. Edit as desired, saving either intermediate
> files or configuration files, as needed.
>
> C. Archive work files as needed.
>
> 3) Use scripted batch processing to apply whatever
> "standard" decorations you choose to for your
> work. For example, a signature/copyright notice,
> borders, or whatever...
>
> 4) Archive final product files as needed.
>
> >In SilkyPix
> > Browse RAWs in thumbnail view with outline display showing
>
> I want to look at each image in full screen size to make
> decisions on actually deleting.
>
> > Right click unwanted images, set delete mark, use file/delete marked
> >when finished
> > Tweak
> > · Use Siklypix defaults - they seem to be very
good
> > . Use 'camera setting' for automatic adjust of
> >colour balance
>
> Color balance is quirky. Often a camera does pretty
> good, so using that as your default is probably good.
> Just be aware that now and then the camera will be
> totally wrong, or that the software might give a better
> balance, or that neither will and you will need to
> manually set it.
>
> > · Max sharpen on drop down menu (is quite
> >conservative)
>
> Set sharpening to zero. Sharpening depends on the
> display, and should be the last thing done before
> printing or uploading to a webpage. It is individually
> done per _useage_.
>
> > Reserve mark those images requiring archive quality. - Develop RAW to
> >TIFF (8 with Exif) using AdobeRGB colour space
> >In Photoshop Elements 2
> >· Read TIFFs
> >. crop
> >· using levels tool adjust max light and dark and mid
> >ones - but not discarding any data at extremes
> >· adjust colour balance - rarely needed cos Silkypix does
it
> >well
>
> If color balance needs adjustment, I'd go all the way
> back to the RAW to image conversion, and do it there
> (basically, start over).
>
> >· if really needed then enhance saturation
> >· touch up/remove unwanted items, blemishes, smooth skin,
> >etc
> >· add more sharpening if Silkypix did not do enough
> >· Reduce noise
>
> Do noise reduction *before* you do anything to sharpen
> it. That includes applying Unsharp Mask techniques too.
>
> >· Convert to web, print etc
> >
> >Delete RAW and the two other files created by the camera for each image.
>
> Don't do that. Archive the RAW files. Write them to
> DVD's or buy a lot of really big disks.
>
> For example you can get SATA to USB 2.0 adapters, and a
> couple of 500 Gb disk drives, all relatively for a low
> price. Write *everything* off to two different disks.
>
> Then disconnect the disks between operations, and leave
> them sitting, unpowered, on the shelf. If one of those
> disks ever does die, *immediately* get another one and
> make a second copy of everything.
>
> >In the above workflow I have not found a need for using DNG from the
Adobe
> >DNG generator. Does the workflow seem reasonable?
>
> I haven't got a clue as to why anyone would use DNG at this
> point.
>
> --
> Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
> Ukpeagvik (Barrow, Alaska)

On Wed, 3 Oct 2007 14:12:30 +0100, "Davy"
<> wrote in
<>:
>"Floyd L. Davidson" <> wrote in message
>news:...
>>Note that the raw image data is 12 bits per pixel and
>>there is only a single channel. The raw data has a
>>Bayer color pattern. Each pixel is one color only, in a
>>RGGB pattern. Part of converting from raw data to an
>>image format is using a group of pixels to determine
>>what each pixel's color would be.
>
>I seem to have bought a really crappy camera; only 12 bpp and doesn't even
>record what the colour of the pixels are !!

Share This Page

Welcome to Velocity Reviews!

Welcome to the Velocity Reviews, the place to come for the latest tech news and reviews.

Please join our friendly community by clicking the button below - it only takes a few seconds and is totally free. You'll be able to chat with other enthusiasts and get tech help from other members.
Sign up now!