Re: RAW vs JPEGs - Does RAW show more detail?

"Floyd Davidson" <floyd@xxxxxxxxxx> wrote:

Much less disk space taken up by the saved metadata and/or cached or
embedded preview than than by a full JPEG conversion.

Disk space is dirt cheap.

Relatively speaking, I suppose. But it is a concern to me right no on
my laptop. A new significantly larger drive is *not* trivially
inexpensive, nor is the process of moving all my stuff over to it.

Far faster to
generate this info - much of it can be done on the fly while you are
tweaking - than to actually generate converted JPEG's.

A. Not true, loading an existing image file is faster.

Only if you've already generated the image. You don't get to substract
off that time from "your" side of the equation.

B. Not true, you can't tweak it until you have it.

True enough, but assuming we are going to be tweaking the image, you
were going to have to do that also before your conversion to JPEG.
Unless your software makes the process so painful that you don't elect
to to do it very often - which would be a huge minus.

And the software
automatically keeps everything in sync - no worries about whether your
JPEG reflects the most recent tweaks you've made.

And no archive of past tweaks that you can return to either. No
multiple versions, each suitable for different uses.

Actually, some programs may support this. And if you need this for
certain images, no one is stopping you from generating individual JPEG
files for those images. Again, I'm talking about general workflow for
the bulk of our images, not handling of the corner cases.

Also no worries about
the files becoming disassociated.

That shouldn't be a worry otherwise, so you point is moot.

Huh? If your software is not doing any "smoke and mirrors", how can you
be sure your files stay associated? It is going to require explicit
work on your part. You might have become accustomed to this and no
longer see the time you are wasting here, but I know I was very aware of
how much easier things became when I didn't have to do that any more.

Of course if you cannot manage a computer in such a way as to
avoid that

It's not a question of not being able to manage the computer. It's a
matter of that not being my job. I don't tell the CPU when to time
slice betwene concurrent jobs, I don't tell the file management system
which sectors to allocate for which blocks data, and I don't tell the
photo software hwo to keep my preview with the RAW data it represents.

And, despite what you may assume, it
is not necessarily any slower to access the image later - the stored
preview can be available immediately, and the process of the doing a

The "stored preview"??? You've been saying there would be no
stored image

Nonsense. I don't think you'll find a single post of mine that does not
use the word "cached" or "embedded" in it somewhere with reference to
this. If I did manage to not mention it once, it's because I made the
imstake of assuming you knew that all of these programs would do this.

... that the whole point was to save disk space
and regenerate the image each time from the raw data.

A preview is not necessarily a full resolution JPEG file, and a cache
need not keep all images around in order to be effective. And saving
space is not the "whole point", it is merely one side benefit. The real
savings is in the data management.

as a
storage place for final products, that idea sucks big time.

Indeed. Luckily, no one ever suggested that. The RAW data itself
retains this role.

Have you never had an image that was used 1) on a web page, 2)
framed in 8x10, 3) framed in 16x20, 4) printed in "wallet size",
and used in a book too?

Yes. A tiny fraction of all the images I've shot, to be sure, and I
have indeed generated different JPEG's for these. Again, I'm not
talking about the exceptions. I talking general workflow and the need
for JPEG conversion of *all* images.

full conversion to display the image in full detail can be done in
background and only on demand.

That is arguing the existence, somewhere, of a single time when
it is actually better; and then saying that therefore it should
also be used when it isn't better. Absurd logic.

I am assuming in this single time you refer to, your sentence above
would have made sense...

In fact, "done in the background" is rarely ever productive for
viewed images (it works for pop-ups on a webpage, but not for
the featured images, for example). "On demand" is virtually
every time an image is used, in most cases, and the viewer is
waiting until it is displayed.

Again, if your software is poor enough not to be able to use
cached/embedded previews.

In some implementations, yes, the XMP file is separate. Or, as I
mentioned elsewhere, with DNG, it can be embedded. But either way,
*you* don't have to worry about "maintaining" this file. The software

Not any more or less than you have to worry about maintaining a
JPEG file.

Completely different. The software can complete hide the XMP from you
if you, and make sure the XMP file is always associated with the RAW
file. I prefer the embedded or even database approach myself. Either
way, it is entirely different than having two separate files that you
manage yourself.

HUGE? Well, it is indeed a huge loss when you cannot manipulate
it as you choose.

I am having trouble imagining a workflow in which there would be even
the slightest need to consider wanting to anything with this file aside
from keep it with its RAW data. Again, if you've got some sort of
non-standard workflow that works for you, I'm not going to stop you.
I'm just interested in letting the people who are not aware that more
modern options exist that eliminate the need for the extra step of JPEG
conversion or, worse, shooting RAW+JPEG just to avoid to pain of the
(unnecesssry) JPEG conversion.

I suppose that for people who really do not
understand it and don't want to, there is some advantage. But
most people recognize that being able to learn a little and
customize their toolset is exactly where they can get ahead.

That's precisely what i was thinking about your reluctance to learn
about modern RAW workflow tools, too...

So... you appear to be impressed by smoke and mirrors... ;-)

They allow me to do my "job" in less disk space, less intervention on
my
part, less chance for error, and - yes - get it all done far faster
than
if I was stopping to generate JPEG's for everything. So yes, while I
am

Reading raw data from disk is faster than reading an existing
image file?

If that was the only thing in m "job" description, then I would answer
no. However, reading raw data from disk is not job. Elsehwere I listed
some common thing I (or any photographer) might want to do. Most are
virtually the same speed regardless of approach. Some are faster with
my workflow, some with yours, although yours is probably faster only if
you get to not count the time you spent doing the conversion to JPEG on
all those files that never really needed it. Add all these times,
prorate for the number of times each task is likely to be performed, and
yes - modern tools allow me to work far faster.

Again, only if you're using RAW software that doens't know how to
effectively use cached or embedded previews to accomplish this.

This is hilarious. Now you are saying the way to beat using a
JPEG is to embed the JPEG into the RAW file. How is that
different, in any beneficial way, than having the JPEG in a
separate file?

In the exact same way that it is benefical for the OS to present that
file to you as a single named entity, and not ask you to keep track of
each section on the disk individually.

Your method requires the original raw data file be re-written
each and every time you do anything to the final product.

Anything that requires a new preview, yes. Either that or store the
preview in a cache, as I have also repeatedly said.

That
inherently involves an unacceptable risk

If you cannot trust trust your OS (you use Linux, no?) to write to a
file, you might want to consider a commercial product like Windows or
Mac tht seems to have worked those bugs, at least, out of their systems.

Of course, that doesn't mean we don't back up our RAW files...

Ever run a batch process to convert 250 or more raw files that
are 20Mb? It is not "transparent".

Indeed, and it is the fact that this need not be done *at all* for
most
images that is a huge advantage for using this type of workflow.

Oh, the fact that you have never taken hundreds of useful images
at one time means that nobody else would ever do so, or want
software that can deal with it?

I have indeed taken hundreds of useful images and have had to process
them. But those were hundreds of images out of *thousands* taken.
Everyone's specific numbers may be different, but no one I know of
shoots in such a way that most of their images need this type of
treatment. If you are an exception for some sort of reason, you have to
realize that puts you in a TINY minority of photographers, and therefore
your advice on what makes for a good workflow should be taken with a
grain of salt. It would be like someone with six fingers on each hand
constantly recommend the general public against buying a paticular brand
of gloves.

And it guarnatees you'll never look at a JPEG that
does not reflect your most recent adjustments?

It guarantees that I *can* look at other than the most recent
adjustments. Your system guarantees that you can't, without
implementing the system you denounce.

I don't denounce it. I simply can say, from experience, that it is
unecessary msot of the time. When it is necessary, I am happy to use
it.

---------------
Marc Sabatella
marc@xxxxxxxxxxxxxxxx

Music, art, & educational materials
Featuring "A Jazz Improvisation Primer"
http://www.outsideshore.com/


.

Relevant Pages

  • Re: Please, why is sky washed out?
    ... +2 compensation and take images simultaneously as ... From my experience there is a lot more to raw data than jpeg, ... if the light situation is difficult: you can safely alter exposure by ...
    (rec.photo.digital)
  • Re: RAW vs JPEGs - Does RAW show more detail?
    ... conversion settings that the user chose when converting it. ... technically it is not saving to the raw file itself, ... JPEG reflects the most recent tweaks you've made. ... and regenerate the image each time from the raw data. ...
    (rec.photo.digital.slr-systems)
  • Re: Free Raw Software for Canon
    ... true RGB conversion but it can be useful for examining RAW data, ... really ruins images somewhat for use as B&W. ... It gives a sharper conversion but with more jaggies, less anti-aliasing filter and a very high gamut output, and a few extra pizels around the edge! ...
    (rec.photo.digital.slr-systems)
  • Re: Free Raw Software for Canon
    ... true RGB conversion but it can be useful for examining RAW data, ... really ruins images somewhat for use as B&W. ... a command-line converter with many output options. ...
    (rec.photo.digital.slr-systems)
  • Re: Image compression benchmark
    ... 16bpp images. ... general idea is to consider this data as "raw data" and consider how ... Concerning image dependence, one can clearly find images that perform ... JPEG and HDPhoto. ...
    (comp.compression)