Archived from groups: rec.photo.digital.slr-systems (More info?)
John Francis wrote:
> In article <cq51rg$544$1@inews.gazeta.pl>,
> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>>John Francis wrote:
>>
>>
>>>True. But that's going to be the case no matter who does the conversion.
>>>But it's a fair bet that software running on a 3GHz Pentium 4 with 1GB of
>>>RAM, and no real time constraints, can probably do a better job than any
>>>in-camera conversion running on a processor whose main design goal is low
>>>power consumption. Plus, of course, if you delay the conversion to a later
>>
>>Bah! Such simple conversion/interpolation can be done on the fly while storing
>>to flash with a handful of machine instructions.
>
>
> I really suggest you do a little research into this subject before
> dismissing it in quite such a cavalier fashion. If all you want is
> some of the most simplistic interpolation, then all it takes is a
> few processor cycles. But that also ends up with some of the worst
> algorithms. There has been quite a bit of research, and more than a
> few thesis papers, done in this field. A good place to start would
> be some of the work referenced in the description accompanying dcraw,
> but that's only one part in a very complex field. The algorithm
> that dcraw uses is more than a plain context-free interpolation, but
> it is still a fairly simple algorithm, with limited requirements for
> processor resources. There are algorithms with much heavier demands.
There are always ways to take complex functions and tune for maximum BW in a
constrained case. Been there.
>>>stage you always have the option of trying a different algorithm if you
>>>don't like the effects on any given image.
>>
>>Camera firmware can be upgraded on most DSLR's.
>
>
> Which just ends up locking you into a different fixed algorithm.
> There's no "best" answer that is appropriate in every case
Or a menu of algorithms. But frankly, beyond a well conceived interpolation of
the R,G,B into RGB, I want to have full control over further sharpenning. (This
attitude, BTW, is the result of having scannned thousands of slides and
negatives. Every image needs USM according to the level of fime detail in the
image.
>>You're confusing me. If no sharpening occurs in camera, then no on the camera
>>values should be considered.
>
>
> What's so difficult to understand? You can set a sharpening parameter
> on the camera, and the value you set is stored along with the image data.
Okay, although that sounds a bit silly. Just give me the least processed image
and let me work it over with USM.
> The later software processing *may* decide to take the value you set as
> a starting point to control how much sharpening to apply. Or it may not,
> and only sharpen based on values set interactively at that time. Just
> which approach is taken depends on how that later stage software is written.
>
> Don't assume all conversion is done interactively, with the photographer
> reviewing each image. Sometimes a converter will be run as a batch process
> to convert a large number of images. In that case it is sometimes worth
> using values selected on-camera (for sharpening, white balance, etc.)
> But in no case is any of the sharpening actually performed in-camera.
Don't assume that I find that acceptable. I'm as lazy as the next guy, but for
detailed images that I want to print large, sharpenning is no less important
than any other aspect of the workflow. I don't want the camera (or the RAW
converter) doing anything to the image that is not reversible. Unless I have
the sharpening algorithm used I can't undo it.
Cheers,
Alan.
--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.
John Francis wrote:
> In article <cq51rg$544$1@inews.gazeta.pl>,
> Alan Browne <alan.browne@freelunchVideotron.ca> wrote:
>
>>John Francis wrote:
>>
>>
>>>True. But that's going to be the case no matter who does the conversion.
>>>But it's a fair bet that software running on a 3GHz Pentium 4 with 1GB of
>>>RAM, and no real time constraints, can probably do a better job than any
>>>in-camera conversion running on a processor whose main design goal is low
>>>power consumption. Plus, of course, if you delay the conversion to a later
>>
>>Bah! Such simple conversion/interpolation can be done on the fly while storing
>>to flash with a handful of machine instructions.
>
>
> I really suggest you do a little research into this subject before
> dismissing it in quite such a cavalier fashion. If all you want is
> some of the most simplistic interpolation, then all it takes is a
> few processor cycles. But that also ends up with some of the worst
> algorithms. There has been quite a bit of research, and more than a
> few thesis papers, done in this field. A good place to start would
> be some of the work referenced in the description accompanying dcraw,
> but that's only one part in a very complex field. The algorithm
> that dcraw uses is more than a plain context-free interpolation, but
> it is still a fairly simple algorithm, with limited requirements for
> processor resources. There are algorithms with much heavier demands.
There are always ways to take complex functions and tune for maximum BW in a
constrained case. Been there.
>>>stage you always have the option of trying a different algorithm if you
>>>don't like the effects on any given image.
>>
>>Camera firmware can be upgraded on most DSLR's.
>
>
> Which just ends up locking you into a different fixed algorithm.
> There's no "best" answer that is appropriate in every case
Or a menu of algorithms. But frankly, beyond a well conceived interpolation of
the R,G,B into RGB, I want to have full control over further sharpenning. (This
attitude, BTW, is the result of having scannned thousands of slides and
negatives. Every image needs USM according to the level of fime detail in the
image.
>>You're confusing me. If no sharpening occurs in camera, then no on the camera
>>values should be considered.
>
>
> What's so difficult to understand? You can set a sharpening parameter
> on the camera, and the value you set is stored along with the image data.
Okay, although that sounds a bit silly. Just give me the least processed image
and let me work it over with USM.
> The later software processing *may* decide to take the value you set as
> a starting point to control how much sharpening to apply. Or it may not,
> and only sharpen based on values set interactively at that time. Just
> which approach is taken depends on how that later stage software is written.
>
> Don't assume all conversion is done interactively, with the photographer
> reviewing each image. Sometimes a converter will be run as a batch process
> to convert a large number of images. In that case it is sometimes worth
> using values selected on-camera (for sharpening, white balance, etc.)
> But in no case is any of the sharpening actually performed in-camera.
Don't assume that I find that acceptable. I'm as lazy as the next guy, but for
detailed images that I want to print large, sharpenning is no less important
than any other aspect of the workflow. I don't want the camera (or the RAW
converter) doing anything to the image that is not reversible. Unless I have
the sharpening algorithm used I can't undo it.
Cheers,
Alan.
--
-- r.p.e.35mm user resource: http://www.aliasimages.com/rpe35mmur.htm
-- r.p.d.slr-systems: http://www.aliasimages.com/rpdslrsysur.htm
-- [SI] gallery & rulz: http://www.pbase.com/shootin
-- e-meil: there's no such thing as a FreeLunch.
Facebook
Twitter
Instagram