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

Discussion in 'Digital Photography' started by Davy, Oct 2, 2007.

  1. Davy

    Davy Guest

    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
     
    Davy, Oct 2, 2007
    #1
    1. Advertising

  2. Davy

    Johnny Lava Guest

    "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.

    Somebody!
     
    Johnny Lava, Oct 2, 2007
    #2
    1. Advertising

  3. Davy

    ray Guest

    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.
     
    ray, Oct 2, 2007
    #3
  4. Re: How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8Has

    "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!

    --
    Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
    Ukpeagvik (Barrow, Alaska)
     
    Floyd L. Davidson, Oct 2, 2007
    #4
  5. Davy

    Davy Guest

    "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, Oct 3, 2007
    #5
  6. 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


    - the channels are (most likely) recorded at 12-bit quantisation

    - at each pixel, only /one/ colour is recorded

    - there may be lossless compression in the raw file

    With no compression, expect 7M x 1.5bytes => 10.5MB

    David
     
    David J Taylor, Oct 3, 2007
    #6
  7. Re: How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8Has

    "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 <http://www.apaflo.com/floyd_davidson>
    Ukpeagvik (Barrow, Alaska)
     
    Floyd L. Davidson, Oct 3, 2007
    #7
  8. Davy

    Davy Guest

    "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
     
    Davy, Oct 3, 2007
    #8
  9. Davy

    ray Guest

    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.
     
    ray, Oct 3, 2007
    #9
  10. Davy

    ray Guest

    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


    Here's the exif data I see:

    ExifTool Version Number : 6.98
    File Name : P1000195.RAW
    Directory : /home/ray
    File Size : 11 MB
    File Modification Date/Time : 2007:10:03 09:42:17
    File Type : RAW
    MIME Type : image/x-raw
    Exif Byte Order : Little-endian (Intel)
    Panasonic Raw Version : 0202
    Sensor Width : 3130
    Sensor Height : 2319
    Sensor Top Border : 7
    Sensor Left Border : 15
    Image Height : 2311
    Image Width : 3087
    ISO : 100
    WB Red Level : 492
    WB Green Level : 263
    WB Blue Level : 434
    Make : Panasonic
    Camera Model Name : DMC-FZ8
    Strip Offsets : 1536
    Orientation : Horizontal (normal)
    Rows Per Strip : 2319
    Strip Byte Counts : 11613552
    Exposure Time : 1/125
    F Number : 4.0
    Exposure Program : Program AE
    Exif Version : 0220
    Date/Time Original : 2007:09:20 15:45:33
    Create Date : 2007:09:20 15:45:33
    Exposure Compensation : 0
    Max Aperture Value : 2.8
    Metering Mode : Multi-segment
    Flash : Off
    Focal Length : 72.0mm
    File Source : Digital Camera
    Aperture : 4.0
    Flash : Off
    Image Size : 3087x2311
    Shutter Speed : 1/125
    Blue Balance : 1.65019
    Focal Length : 72.0mm
    Light Value : 11.0
    Red Balance : 1.870722
     
    ray, Oct 3, 2007
    #10
  11. Re: How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8Has

    "Davy" <> wrote:
    >
    >http://www.callnetuk.com/home/davystokes/photos.htm
    >- click on the hyperlink at the top of the page


    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 a dump from /exiftool/ that shows everything it
    found:

    ExifTool Version Number : 6.96
    File Name : P1000195.RAW
    Directory : .
    File Size : 11 MB
    File Modification Date/Time : 2007:10:03 08:47:07
    File Type : RAW
    MIME Type : image/x-raw
    Panasonic Raw Version : 0202
    Sensor Width : 3130
    Sensor Height : 2319
    Sensor Top Border : 7
    Sensor Left Border : 15
    Image Height : 2311
    Image Width : 3087
    ISO : 100
    WB Red Level : 492
    WB Green Level : 263
    WB Blue Level : 434
    Make : Panasonic
    Camera Model Name : DMC-FZ8
    Strip Offsets : 1536
    Orientation : Horizontal (normal)
    Rows Per Strip : 2319
    Strip Byte Counts : 11613552
    Exposure Time : 1/125
    F Number : 4.0
    Exposure Program : Program AE
    Exif Version : 0220
    Date/Time Original : 2007:09:20 15:45:33
    Create Date : 2007:09:20 15:45:33
    Exposure Compensation : 0
    Max Aperture Value : 2.8
    Metering Mode : Multi-segment
    Flash : Off
    Focal Length : 72.0mm
    File Source : Digital Camera
    Aperture : 4.0
    Flash : Off
    Image Size : 3087x2311
    Shutter Speed : 1/125
    Blue Balance : 1.65019
    Focal Length : 72.0mm
    Light Value : 11.0
    Red Balance : 1.870722

    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.

    ExifTool Version Number : 6.96
    File Name : nightshot.jpg
    Directory : .
    File Size : 3 MB
    File Modification Date/Time : 2007:10:03 02:48:45
    File Type : JPEG
    MIME Type : image/jpeg
    Make : Panasonic
    Camera Model Name : DMC-FZ8
    Orientation : Horizontal (normal)
    X Resolution : 72
    Y Resolution : 72
    Resolution Unit : inches
    Software : Ver.1.0
    Modify Date : 2007:05:31 21:50:04
    Y Cb Cr Positioning : Co-sited
    Exposure Time : 4
    F Number : 3.6
    Exposure Program : Shutter speed priority AE
    ISO : 100
    Exif Version : 0221
    Date/Time Original : 2007:05:31 21:50:04
    Create Date : 2007:05:31 21:50:04
    Components Configuration : YCbCr
    Compressed Bits Per Pixel : 4
    Exposure Compensation : 0
    Max Aperture Value : 2.8
    Metering Mode : Multi-segment
    Light Source : Unknown (0)
    Flash : Off
    Focal Length : 21.6mm
    Image Quality : High
    Firmware Version : 0.1.0.2
    White Balance : Auto
    Focus Mode : Auto
    AF Mode : 1-area (high speed)
    Image Stabilization : Off
    Macro Mode : Off
    Shooting Mode : Shutter Priority
    Audio : No
    Data Dump : (Binary data 6152 bytes, use -b option to extract)
    Flash Bias : 0
    Internal Serial Number : (S02) 2007:02:13 no. 0713
    Panasonic Exif Version : 0220
    Color Effect : Off
    Time Since Power On : 00:02:55.11
    Burst Mode : Off
    Sequence Number : 0
    Noise Reduction : Standard
    Self Timer : 2s
    Rotation : Horizontal (normal)
    Color Mode : Normal
    Optical Zoom Mode : Standard
    Conversion Lens : Off
    Travel Day : n/a
    World Time Location : Home
    Program ISO : 100
    WB Adjust AB : 0
    WB Adjust GM : 0
    Maker Note Version : 0101
    Scene Mode : Off
    WB Red Level : 1291
    WB Green Level : 1054
    WB Blue Level : 2795
    Baby Age : (not set)
    Flashpix Version : 0100
    Color Space : sRGB
    Exif Image Width : 3072
    Exif Image Length : 2304
    Interoperability Index : R98 - DCF basic file (sRGB)
    Interoperability Version : 0100
    Sensing Method : One-chip color area
    File Source : Digital Camera
    Scene Type : Directly photographed
    Custom Rendered : Normal
    Exposure Mode : Auto
    Digital Zoom Ratio : 0
    Focal Length In 35mm Format : 130mm
    Scene Capture Type : Standard
    Gain Control : None
    Contrast : Normal
    Saturation : Normal
    Sharpness : Normal
    Compression : JPEG (old-style)
    Thumbnail Offset : 8096
    Thumbnail Length : 4820
    Image Width : 3072
    Image Height : 2304
    Encoding Process : Baseline DCT, Huffman coding
    Bits Per Sample : 8
    Color Components : 3
    Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)
    Aperture : 3.6
    Blue Balance : 2.651803
    Image Size : 3072x2304
    Red Balance : 1.224858
    Scale Factor To 35mm Equivalent : 6.0
    Shutter Speed : 4
    Thumbnail Image : (Binary data 4820 bytes, use -b option to extract)
    Circle Of Confusion : 0.005 mm
    Focal Length : 21.6mm (35mm equivalent: 130.0mm)
    Hyperfocal Distance : 25.96 m
    Light Value : 1.7

    --
    Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
    Ukpeagvik (Barrow, Alaska)
     
    Floyd L. Davidson, Oct 3, 2007
    #11
  12. Davy

    Davy Guest

    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?

    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?

    In SilkyPix
    Browse RAWs in thumbnail view with outline display showing
    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
    · Max sharpen on drop down menu (is quite
    conservative)
    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 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
    · Convert to web, print etc

    Delete RAW and the two other files created by the camera for each image.

    In the above workflow I have not found a need for using DNG from the Adobe
    DNG generator. Does the workflow seem reasonable?

    cheers

    Davy

    "Floyd L. Davidson" <> wrote in message
    news:...
    > "Davy" <> wrote:
    > >
    > >http://www.callnetuk.com/home/davystokes/photos.htm
    > >- click on the hyperlink at the top of the page

    >
    > 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 a dump from /exiftool/ that shows everything it
    > found:
    >
    > ExifTool Version Number : 6.96
    > File Name : P1000195.RAW
    > Directory : .
    > File Size : 11 MB
    > File Modification Date/Time : 2007:10:03 08:47:07
    > File Type : RAW
    > MIME Type : image/x-raw
    > Panasonic Raw Version : 0202
    > Sensor Width : 3130
    > Sensor Height : 2319
    > Sensor Top Border : 7
    > Sensor Left Border : 15
    > Image Height : 2311
    > Image Width : 3087
    > ISO : 100
    > WB Red Level : 492
    > WB Green Level : 263
    > WB Blue Level : 434
    > Make : Panasonic
    > Camera Model Name : DMC-FZ8
    > Strip Offsets : 1536
    > Orientation : Horizontal (normal)
    > Rows Per Strip : 2319
    > Strip Byte Counts : 11613552
    > Exposure Time : 1/125
    > F Number : 4.0
    > Exposure Program : Program AE
    > Exif Version : 0220
    > Date/Time Original : 2007:09:20 15:45:33
    > Create Date : 2007:09:20 15:45:33
    > Exposure Compensation : 0
    > Max Aperture Value : 2.8
    > Metering Mode : Multi-segment
    > Flash : Off
    > Focal Length : 72.0mm
    > File Source : Digital Camera
    > Aperture : 4.0
    > Flash : Off
    > Image Size : 3087x2311
    > Shutter Speed : 1/125
    > Blue Balance : 1.65019
    > Focal Length : 72.0mm
    > Light Value : 11.0
    > Red Balance : 1.870722
    >
    > 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.
    >
    > ExifTool Version Number : 6.96
    > File Name : nightshot.jpg
    > Directory : .
    > File Size : 3 MB
    > File Modification Date/Time : 2007:10:03 02:48:45
    > File Type : JPEG
    > MIME Type : image/jpeg
    > Make : Panasonic
    > Camera Model Name : DMC-FZ8
    > Orientation : Horizontal (normal)
    > X Resolution : 72
    > Y Resolution : 72
    > Resolution Unit : inches
    > Software : Ver.1.0
    > Modify Date : 2007:05:31 21:50:04
    > Y Cb Cr Positioning : Co-sited
    > Exposure Time : 4
    > F Number : 3.6
    > Exposure Program : Shutter speed priority AE
    > ISO : 100
    > Exif Version : 0221
    > Date/Time Original : 2007:05:31 21:50:04
    > Create Date : 2007:05:31 21:50:04
    > Components Configuration : YCbCr
    > Compressed Bits Per Pixel : 4
    > Exposure Compensation : 0
    > Max Aperture Value : 2.8
    > Metering Mode : Multi-segment
    > Light Source : Unknown (0)
    > Flash : Off
    > Focal Length : 21.6mm
    > Image Quality : High
    > Firmware Version : 0.1.0.2
    > White Balance : Auto
    > Focus Mode : Auto
    > AF Mode : 1-area (high speed)
    > Image Stabilization : Off
    > Macro Mode : Off
    > Shooting Mode : Shutter Priority
    > Audio : No
    > Data Dump : (Binary data 6152 bytes, use -b option

    to extract)
    > Flash Bias : 0
    > Internal Serial Number : (S02) 2007:02:13 no. 0713
    > Panasonic Exif Version : 0220
    > Color Effect : Off
    > Time Since Power On : 00:02:55.11
    > Burst Mode : Off
    > Sequence Number : 0
    > Noise Reduction : Standard
    > Self Timer : 2s
    > Rotation : Horizontal (normal)
    > Color Mode : Normal
    > Optical Zoom Mode : Standard
    > Conversion Lens : Off
    > Travel Day : n/a
    > World Time Location : Home
    > Program ISO : 100
    > WB Adjust AB : 0
    > WB Adjust GM : 0
    > Maker Note Version : 0101
    > Scene Mode : Off
    > WB Red Level : 1291
    > WB Green Level : 1054
    > WB Blue Level : 2795
    > Baby Age : (not set)
    > Flashpix Version : 0100
    > Color Space : sRGB
    > Exif Image Width : 3072
    > Exif Image Length : 2304
    > Interoperability Index : R98 - DCF basic file (sRGB)
    > Interoperability Version : 0100
    > Sensing Method : One-chip color area
    > File Source : Digital Camera
    > Scene Type : Directly photographed
    > Custom Rendered : Normal
    > Exposure Mode : Auto
    > Digital Zoom Ratio : 0
    > Focal Length In 35mm Format : 130mm
    > Scene Capture Type : Standard
    > Gain Control : None
    > Contrast : Normal
    > Saturation : Normal
    > Sharpness : Normal
    > Compression : JPEG (old-style)
    > Thumbnail Offset : 8096
    > Thumbnail Length : 4820
    > Image Width : 3072
    > Image Height : 2304
    > Encoding Process : Baseline DCT, Huffman coding
    > Bits Per Sample : 8
    > Color Components : 3
    > Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)
    > Aperture : 3.6
    > Blue Balance : 2.651803
    > Image Size : 3072x2304
    > Red Balance : 1.224858
    > Scale Factor To 35mm Equivalent : 6.0
    > Shutter Speed : 4
    > Thumbnail Image : (Binary data 4820 bytes, use -b option

    to extract)
    > Circle Of Confusion : 0.005 mm
    > Focal Length : 21.6mm (35mm equivalent: 130.0mm)
    > Hyperfocal Distance : 25.96 m
    > Light Value : 1.7
    >
    > --
    > Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
    > Ukpeagvik (Barrow, Alaska)
    >
     
    Davy, Oct 4, 2007
    #12
  13. 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.
     
    ChesterCharlston, Oct 4, 2007
    #13
  14. Re: How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8Has

    "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 L. Davidson, Oct 4, 2007
    #14
  15. Davy

    Guest

    Re: How Do I Know What Bits per Pixel my Panasonic Lumix DMC-FZ8Has

    (ChesterCharlston)
    wrote:

    " 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. "

    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

    His posting just goes to show that
    Floyd L. D. is a 'real' A-hole. ((O))
     
    , Oct 4, 2007
    #15
  16. Davy

    ray Guest

    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?


    FWIW:
    I find that reading the raw data into 'ufraw' allows me to make most of
    the changes I need for color balance, exposure, curves, etc. - I save out
    a jpeg. I then may make a few adjustments in GIMP before printing or
    posting, and do other processing like panorama stitching.

    >
    > In SilkyPix
    > Browse RAWs in thumbnail view with outline display showing
    > 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
    > · Max sharpen on drop down menu (is quite
    > conservative)
    > 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 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
    > · Convert to web, print etc
    >
    > Delete RAW and the two other files created by the camera for each image.
    >
    > In the above workflow I have not found a need for using DNG from the Adobe
    > DNG generator. Does the workflow seem reasonable?
    >
    > cheers
    >
    > Davy
    >
    > "Floyd L. Davidson" <> wrote in message
    > news:...
    >> "Davy" <> wrote:
    >> >
    >> >http://www.callnetuk.com/home/davystokes/photos.htm
    >> >- click on the hyperlink at the top of the page

    >>
    >> 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 a dump from /exiftool/ that shows everything it
    >> found:
    >>
    >> ExifTool Version Number : 6.96
    >> File Name : P1000195.RAW
    >> Directory : .
    >> File Size : 11 MB
    >> File Modification Date/Time : 2007:10:03 08:47:07
    >> File Type : RAW
    >> MIME Type : image/x-raw
    >> Panasonic Raw Version : 0202
    >> Sensor Width : 3130
    >> Sensor Height : 2319
    >> Sensor Top Border : 7
    >> Sensor Left Border : 15
    >> Image Height : 2311
    >> Image Width : 3087
    >> ISO : 100
    >> WB Red Level : 492
    >> WB Green Level : 263
    >> WB Blue Level : 434
    >> Make : Panasonic
    >> Camera Model Name : DMC-FZ8
    >> Strip Offsets : 1536
    >> Orientation : Horizontal (normal)
    >> Rows Per Strip : 2319
    >> Strip Byte Counts : 11613552
    >> Exposure Time : 1/125
    >> F Number : 4.0
    >> Exposure Program : Program AE
    >> Exif Version : 0220
    >> Date/Time Original : 2007:09:20 15:45:33
    >> Create Date : 2007:09:20 15:45:33
    >> Exposure Compensation : 0
    >> Max Aperture Value : 2.8
    >> Metering Mode : Multi-segment
    >> Flash : Off
    >> Focal Length : 72.0mm
    >> File Source : Digital Camera
    >> Aperture : 4.0
    >> Flash : Off
    >> Image Size : 3087x2311
    >> Shutter Speed : 1/125
    >> Blue Balance : 1.65019
    >> Focal Length : 72.0mm
    >> Light Value : 11.0
    >> Red Balance : 1.870722
    >>
    >> 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.
    >>
    >> ExifTool Version Number : 6.96
    >> File Name : nightshot.jpg
    >> Directory : .
    >> File Size : 3 MB
    >> File Modification Date/Time : 2007:10:03 02:48:45
    >> File Type : JPEG
    >> MIME Type : image/jpeg
    >> Make : Panasonic
    >> Camera Model Name : DMC-FZ8
    >> Orientation : Horizontal (normal)
    >> X Resolution : 72
    >> Y Resolution : 72
    >> Resolution Unit : inches
    >> Software : Ver.1.0
    >> Modify Date : 2007:05:31 21:50:04
    >> Y Cb Cr Positioning : Co-sited
    >> Exposure Time : 4
    >> F Number : 3.6
    >> Exposure Program : Shutter speed priority AE
    >> ISO : 100
    >> Exif Version : 0221
    >> Date/Time Original : 2007:05:31 21:50:04
    >> Create Date : 2007:05:31 21:50:04
    >> Components Configuration : YCbCr
    >> Compressed Bits Per Pixel : 4
    >> Exposure Compensation : 0
    >> Max Aperture Value : 2.8
    >> Metering Mode : Multi-segment
    >> Light Source : Unknown (0)
    >> Flash : Off
    >> Focal Length : 21.6mm
    >> Image Quality : High
    >> Firmware Version : 0.1.0.2
    >> White Balance : Auto
    >> Focus Mode : Auto
    >> AF Mode : 1-area (high speed)
    >> Image Stabilization : Off
    >> Macro Mode : Off
    >> Shooting Mode : Shutter Priority
    >> Audio : No
    >> Data Dump : (Binary data 6152 bytes, use -b option

    > to extract)
    >> Flash Bias : 0
    >> Internal Serial Number : (S02) 2007:02:13 no. 0713
    >> Panasonic Exif Version : 0220
    >> Color Effect : Off
    >> Time Since Power On : 00:02:55.11
    >> Burst Mode : Off
    >> Sequence Number : 0
    >> Noise Reduction : Standard
    >> Self Timer : 2s
    >> Rotation : Horizontal (normal)
    >> Color Mode : Normal
    >> Optical Zoom Mode : Standard
    >> Conversion Lens : Off
    >> Travel Day : n/a
    >> World Time Location : Home
    >> Program ISO : 100
    >> WB Adjust AB : 0
    >> WB Adjust GM : 0
    >> Maker Note Version : 0101
    >> Scene Mode : Off
    >> WB Red Level : 1291
    >> WB Green Level : 1054
    >> WB Blue Level : 2795
    >> Baby Age : (not set)
    >> Flashpix Version : 0100
    >> Color Space : sRGB
    >> Exif Image Width : 3072
    >> Exif Image Length : 2304
    >> Interoperability Index : R98 - DCF basic file (sRGB)
    >> Interoperability Version : 0100
    >> Sensing Method : One-chip color area
    >> File Source : Digital Camera
    >> Scene Type : Directly photographed
    >> Custom Rendered : Normal
    >> Exposure Mode : Auto
    >> Digital Zoom Ratio : 0
    >> Focal Length In 35mm Format : 130mm
    >> Scene Capture Type : Standard
    >> Gain Control : None
    >> Contrast : Normal
    >> Saturation : Normal
    >> Sharpness : Normal
    >> Compression : JPEG (old-style)
    >> Thumbnail Offset : 8096
    >> Thumbnail Length : 4820
    >> Image Width : 3072
    >> Image Height : 2304
    >> Encoding Process : Baseline DCT, Huffman coding
    >> Bits Per Sample : 8
    >> Color Components : 3
    >> Y Cb Cr Sub Sampling : YCbCr4:2:2 (2 1)
    >> Aperture : 3.6
    >> Blue Balance : 2.651803
    >> Image Size : 3072x2304
    >> Red Balance : 1.224858
    >> Scale Factor To 35mm Equivalent : 6.0
    >> Shutter Speed : 4
    >> Thumbnail Image : (Binary data 4820 bytes, use -b option

    > to extract)
    >> Circle Of Confusion : 0.005 mm
    >> Focal Length : 21.6mm (35mm equivalent: 130.0mm)
    >> Hyperfocal Distance : 25.96 m
    >> Light Value : 1.7
    >>
    >> --
    >> Floyd L. Davidson <http://www.apaflo.com/floyd_davidson>
    >> Ukpeagvik (Barrow, Alaska)
    >>
     
    ray, Oct 5, 2007
    #16
  17. Davy

    Alan Meyer Guest

    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.

    Alan
     
    Alan Meyer, Oct 5, 2007
    #17
  18. Davy

    Davy Guest

    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)
     
    Davy, Oct 5, 2007
    #18
  19. Davy

    Davy Guest

    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)
     
    Davy, Oct 8, 2007
    #19
  20. Davy

    John Navas Guest

    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 !! :)


    Not so!

    That's a function of the Bayer filters used in the great majority of
    digital cameras -- see http://en.wikipedia.org/wiki/Bayer_filter

    The FZ8 is an excellent "real" digital camera.

    --
    Best regards,
    John Navas <http:/navasgroup.com>
     
    John Navas, Oct 15, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Al Dykes
    Replies:
    3
    Views:
    1,246
    Tony Spadaro
    Dec 29, 2003
  2. peggy83

    bits per pixel VS bits per channel

    peggy83, Oct 10, 2006, in forum: Digital Photography
    Replies:
    1
    Views:
    954
    Scott W
    Oct 10, 2006
  3. Panasonic Lumix Fz8 vs Fz50

    , May 20, 2007, in forum: Digital Photography
    Replies:
    12
    Views:
    686
    Michael J Davis
    May 24, 2007
  4. Davy
    Replies:
    13
    Views:
    4,651
    John Navas
    Oct 16, 2007
  5. sobriquet

    Panasonic Lumix DMC-FZ38 vs DMC-FZ35

    sobriquet, Oct 4, 2009, in forum: Digital Photography
    Replies:
    1
    Views:
    1,420
    sobriquet
    Oct 4, 2009
Loading...

Share This Page