Skip to content

Shooting Technique, Workflow and Editing / Archived topic

Raw vs. Jpeg - the advantages & disadvantages

Started by Paul Kay ·

  • 27Posts
  • 27Replies

Read-only discussion

Raw vs. Jpeg - the advantages & disadvantages

27 posts
  1. Would the lack of preview and and colour profile save enough to make a difference?

     

    Alex

  2. Any idea why that is?

     

     

    No. I was hoping somebody could tell me.

     

    I still build my website galleries the hard way. Instead of using one of these cool new gallery-generating applications I generate thumbnails manually. Until recently I had given up on generating high-quality, small thumbnail files using Photoshop. I used Macromedia Fireworks for jpeg conversion instead. Recently I "discovered" that Photoshop's Save for Web command is able to generate the small thumbnails files that the Save As, Jpeg command can't.

     

    -Brad

  3. Brad, I don't understand how a thumb size image file can be so big. The most recent image I posted on this thread is 600x400 save with "Save As - jpeg" with color profile at quality 9 and came out aboiut 65k bytes. This thumb size of it at quality 9 using "Save As" with color profile is 14k

     

    shark1raw3thumb.jpg

    Edited by herbko
  4. Ok, with a bit of research on the Apple support forums I believe I've determined why my jpeg file sizes are so large. This issue effects all Macintosh users using Photoshop.

    Files created on a Mac contain both a data fork and a resource fork. The data fork contains the actual jpeg data. The resource fork contains some extraneous data including the preview icon. When a jpeg is created using Photoshop's Save As - Jpeg command approximately 50 kilobytes of resource fork data is added to the file by Photoshop. This extra baggage becomes most apparent when you are attempting to create a small jpeg for web consumption.

    Fortunately there are several simple ways to reduce or eliminate the resource fork:

    1. Within Photoshop use "Save for Web" instead of "Save As - Jpeg".

    2. Dragging Jpeg images into a web browser window, then back out again will strip away the resource fork.

    3. The FTP application you use to upload images onto your web server will strip the resource fork automatically.

     

    Here are two discussions on the subject:

    http://discussions.info.apple.com/webx?128...173.0@.68bc3d91

    http://discussions.info.apple.com/webx?13@...l.0@.68b87eb0/0

     

    Unfortunately I have not fully solved my problem. This morning I created three 100x150 pixel files in three different ways:

     

    1. Save As - Jpeg, quality 8

    size: 48.2K

    size with resource fork: 104K

    pipefish_SAJ.jpg

     

    2. Save As - Jpeg, quality 3

    size: 45.8K

    size with resource fork: 102K

    pipefish_SAJ_3.jpg

     

    3. Save for Web, quality 70%

    size: 12K

    size with resource fork (if there is one): 12K

    pipefish_SFW.jpg

     

    I should also add that I converted the file to sRGB prior to saving.

     

    46K is too large for an image of these dimensions. It's also a bit strange that image quality settings did not effect file size much.

    I'll stick with Save for Web.

     

    -Brad

    Edited by BradDB
  5. We've kind of drifted from the original post but I am the snapper to whom John Bantin refers to about the poor quality of JPEG reproduction in DIVE magazine. John, thank you for your compliment about the image, however, your post totally confirms the myths and misunderstanding about RAW and JPEG files. This was in fact reproduced from a RAW file. The problem was in the repro stage – won’t bore everyone with the details but it was just a change in monitors. There are exactly the same number of pixels in a JPEG as a RAW file, so the SIZE of repro that you can take them to is the same. To give you the other side of the coin a similar shot submitted as JPEG was highly commended in this years Natural History Museum Wildlife Photographer of the year and has been blown up to around A0 size at the museum.

  6. Jpeg files are compressed. They are lossy files, BUT the degredation which this entails depends on compression setting AND the original photographs content. I haven't seen the photo in DIVE but the whole point that I have been trying to make is that processing the Raw image in the best possible way - ie adjusting in the Raw converter, retaining the tiff file as a 16-bit file for refining adjustments and then, finally converting it to an 8-bit tiff, OR jpeg file, will produce a potentially far better image than adjusting a jpeg image.

     

    The number of pixels in an image won't vary whether it is a jpeg or raw but the quality of the pixels most certainly does!

     

    Starting with a good jpeg file (ie well exposed, in-camera colour corrected, etc) should lead to a minimally adjusted good final jpeg file. However if you are trying to squeeze every last piece of information out of a file them carrying out all adjustments on as much information as you can obtain is obviously the way to go. I'm producing 30" x 20" prints which surpass anything I've ever got out of 35mm in terms of sharpness, smoothness and overall image quality, but this size is pushing an 11 MPixel file so I need every ounce of quality I can get. Sure Jpegs are useful if speed is of over-riding importance, but they do not always represent the quality available from current dSLRs. Just like using a cheap lens, a jpeg will be fine if it is not pushed too hard.

  7. To add on to what pgk was saying, the amount of data lost due to compression in jpeg files does indeed depend on compression setting and the nature of the original, but is also cumulative. I think a lot of the really bad examples of JPEG degradation are due to someone saving and reopening a file in JPEG format multiple times. This can lead to really nasty artifacts. Keeping the working copy of an image file in TIFF (or another lossless format) and making single generation JPEGs from that with low compression settings can mean no noticeable degradation.

     

    The JPEG compression algorhythm tends do do most of its work in the blue channel, because the effects of cutting back the data here is less noticable for most typical photographic subjects. This isn't necessarily the case for u/w, and I suspect this is why the jpeg format is more problematic for underwater photography, e.g., producing noticeable banding when there is a continuous gradient of blues in the background water. An easy way to check for damage due to JPEG compression is just to look at the blue channel. If there are any nasty artifacts, you should be able to see them easily.

     

    There's no question in my mind the best way to go is to start from RAW and keep the master working file in TIFF (or PSD) format, generating JPEG files from that master file if they are needed. If you are starting with a JPEG original, the important thing is to convert that file to TIFF (or PSD) before saving the file after any processing, particularly if you will be reopening the file and processing further, rather than saving the working file in JPEG format.

     

    Frogfish (Robert Delfs)

Reef Photo & Video

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.