How to get the best from PTgui's RAW photo handling
Roger D. Williams
RAW photo handling capabilities?
Both the 8mm f/3.5 Sigma and the 10.5mm f/2.8 Nikon fisheyes
have CA that needs correcting to get the best results.
PTgui has long had the ability to correct for vignetting.
Could it also be given the ability to correct CA? Does it
have it already? Or should I be pre-processing with DX0
or Silkypix?
Roger W
--
Work: www.adex-japan.com
Erik Krause
Pre-processing is probably the easiest way. dcraw has the ability to
correct for CA - you must supply correction parameters for red and blue
channel - but there currently is no possibility to add those parameters
to the dcraw command line from within PTGui.
But I see little point in adding this feature to PTGui: dcraw is very
good in decoding various RAW formats but it's fairly bad in processing
them (although it has improved) - and the RAW data needs extensive
processing before you want to see it.
Hence most universal RAW converters use the decoding part of dcraw but
almost none uses the processing part. If you want to go for quality an
external RAW converter is mandatory.
One could argue that a dcraw additional parameters section in the PTGui
options wouldn't cost too much. Stays the problem to determine the
correct parameters. There is a way using some hugin command line
programs, but I guess someone who wants to use RAW conversion from
within PTGui won't dive into that.
Another possibility would be the use of PTShift from
http://www.pinlady.net/vr/ but in this case you need to transform the
parameters somehow...
--
Erik Krause
http://www.erik-krause.de
Keith Martin
>Hence most universal RAW converters use the decoding part of dcraw but
>almost none uses the processing part. If you want to go for quality an
>external RAW converter is mandatory.
Fair enough and good to know. It is good to see such developments and
it can clearly streamline workflows, but I can see that it isn't for
everyone.
k
Joergen Geerds
your raw files say in bridge, LR, ACR or whatever you prefer, and then
use the newly generated sidecar file to feed the proper parameters
into dcraw while opening them in ptgui??
applying repeating parameters like CA, WB, sharpening etc is just 1
click in bridge (and I would argue again that the majority of people
here have photoshop and bridge installed, and maybe 6 who don't have/
like photoshop), and most of us probably have those CA parameters
saved as presets anyway... and since the xmp files are clean xml
files, it shouldn't be so hard to read those settings, and convert
them to the proper command for dcraw... or am I wrong with my
assumption?
joergen
Keith Martin
>use the newly generated sidecar file to feed the proper parameters
>into dcraw while opening them in ptgui??
I love this idea.
k
Erik Krause
> in an ideal world, wouldn't it be nice to set all your parameter for
> your raw files say in bridge, LR, ACR or whatever you prefer, and then
> use the newly generated sidecar file to feed the proper parameters
> into dcraw while opening them in ptgui??
You would not want to live in an ideal world: No challenge anymore... ;-)
However, dcraw has not the capabilities of LR or ACR or bridge, that's
why those applications exist. But if one of those applications would
offer an interface or at least a possibility to run it from the command
line it would be possible to use it as a plugin in PTGui.
Long, long time ago, when OLE was invented I hoped that something like
that would be possible some times: that each program could use any
functionality of another program as a module. But still many many years
later there are mostly proprietary programs that can't interact with
others.
Joergen Geerds
> However, dcraw has not the capabilities of LR or ACR or bridge, that's
> why those applications exist. But if one of those applications would
> offer an interface or at least a possibility to run it from the command
> line it would be possible to use it as a plugin in PTGui.
i know that ACR has by far more/different features than dcraw... I was
proposing to parse the sidecar file and grab whatever dcraw can do,
and ignore the rest... that way we could get the best of both worlds,
or at least a working compromise... (I think the CA, together with WB
are probably the most important parameters to grab from the sidecar
file).
joost: do you have any opinion on this?
joergen
Roger D. Williams
On Mon, 26 Jan 2009 04:34:52 +0900, Erik Krause <erik....@gmx.de> wrote:
>
> Roger D. Williams wrote:
>
>> What is the workflow for eliminating CA when using PTgui's
>> RAW photo handling capabilities?
>
> Pre-processing is probably the easiest way. dcraw has the ability to
> correct for CA - you must supply correction parameters for red and blue
> channel - but there currently is no possibility to add those parameters
> to the dcraw command line from within PTGui.
I see.
> But I see little point in adding this feature to PTGui: dcraw is very
> good in decoding various RAW formats but it's fairly bad in processing
> them (although it has improved) - and the RAW data needs extensive
> processing before you want to see it.
Not sure what you mean here. Do you mean I should be doing a lot of
pre-processing of my RAW images before I let PTgui work on them? I do
not really see the need for this, and it would be very time-consuming.
> Hence most universal RAW converters use the decoding part of dcraw but
> almost none uses the processing part. If you want to go for quality an
> external RAW converter is mandatory.
I tried RAWTHERAPEE and wasn't very impressed with its correction of
CA. I will probably stick with Silkypix (and DX0 for lens/camera
combinations for which it has modules--unfortunately not the D300 plus
Sigma 8mm f/3.5).
> One could argue that a dcraw additional parameters section in the PTGui
> options wouldn't cost too much. Stays the problem to determine the
> correct parameters. There is a way using some hugin command line
> programs, but I guess someone who wants to use RAW conversion from
> within PTGui won't dive into that.
For a first approximation the correct parameters could be tied to the
lens. One set for Sigma 8mm and another for Nikon 10.5mm. That would
take care of most CA for many panoramacists (and all of mine <g>).
> Another possibility would be the use of PTShift from
> http://www.pinlady.net/vr/ but in this case you need to transform the
> parameters somehow...
Not famiiiar with this. Will look into it. Thanks again...
Am I right to assume that once I have run my RAW imnages through an
image processing program the changes will be stored with the image
and therefore accessible to PTgui?
Roger W.
>
--
Work: www.adex-japan.com
Keith Martin
>Am I right to assume that once I have run my RAW imnages through an
>image processing program the changes will be stored with the image
>and therefore accessible to PTgui?
The RAW files themselves aren't changed, but 'sidecar' files that
describe the last-set alterations are saved alongside the actual RAW
files.
k
Ken Warner
name to sidecar? I didn't get the memo...
Roger D. Williams
>
> Roger D. Williams wrote:
>
>> What is the workflow for eliminating CA when using PTgui's
>> RAW photo handling capabilities?
>>
> Another possibility would be the use of PTShift from
> http://www.pinlady.net/vr/ but in this case you need to transform the
> parameters somehow...
Thank you, Erik.
I have looked at this. This is a plugin for PhotoShop that will work
with CS and CS2 (which I have on my home and office computers). So
presumably a PS "action" (which I assume is a kind of batch file)
would apply the same correction parameters to all the images selected.
But then I would have had to convert all the RAW to TIFF. <sigh>
Unless there were some way of incorporating this into the internal
workings of PTgui. Which seems unlikely...
I don't understand what you mean by "transform the parameters" though.
Is it that the PanoTools a, b & c parameters are not the same as the
ones that the latest version of PTgui uses?
I must say that this plug-in seems to offer the most comprehensive
approach to compensating for CA.
Erik Krause
> I have looked at this. This is a plugin for PhotoShop that will work
> with CS and CS2 (which I have on my home and office computers). So
> presumably a PS "action" (which I assume is a kind of batch file)
> would apply the same correction parameters to all the images selected.
Not exactly. PTShift determines the parameters only. They where
originally meant for the panotools Radial Shift filter which is part of
the panotools photoshop plugins. BTW.: PTGui has an interface to the
plugins, too. Just press the "Correct" button on PTGui Source images tab
(needs panotools to be installed).
> But then I would have had to convert all the RAW to TIFF.
Yes, and that's the downside. Since CA is best corrected in RAW.
> I don't understand what you mean by "transform the parameters" though.
Transformed for dcraw. dcraw wants two parameters. It does a linear
correction only whereas panotools do a polynomial one (same as lens
distortion).
> Is it that the PanoTools a, b & c parameters are not the same as the
> ones that the latest version of PTgui uses?
Yes, they are the same. But in case of CA correction they need to be
used on separate color channels instead of the same image. That's what
radial shift filter does.
> I must say that this plug-in seems to offer the most comprehensive
> approach to compensating for CA.
Yes, they do. Unfortunately they don't work on RAW image data. My dream
application would be a RAW converter with an interface to radial shift
filter.
However, I had a discussion with Thomas Niemann (Author of PTLens) about
linear versus polynomial CA correction and his point was that he didn't
see a an image where polynomial was really necessary. And he has the
overview since for PTLens he calibrated a lot of lenses. So may be
linear correction (what all RAW converters do if they offer CA
correction) is enough for real world lenses.
PTShift might be a bit of overkill to determine correction parameters
for dcraw. Perhaps it is enough to use the numbers from your RAW
converter together with a correction factor. This would be a matter of
experimenting...
On the other hand: Why not do RAW conversion in an external RAW
converter (including CA correction) and use PTGui where it's main
strength is - for stitching? Ok, you have those intermediate TIFF files,
but it should be small effort to delete them once your panorama is
ready. This can even be automated using a shell script.
PTGui Support
Sorry to spoil your dream, but the sidecar file contains settings
specific to Adobe's own algorithms, so it's only meaningful in
conjunction with Adobe's own Raw converter.
Joost
Keith Martin
>uhmmm.. when did meta files decide to change their
>name to sidecar? I didn't get the memo...
[ahem] Single quotes around the word indicate attribution of the
quoted material to someone else. :-) Here, this is actually a
colloquial term used by Adobe specifically and many photographers
generically. 'Sidecar' is a term I don't particularly like either,
but is pretty common parlance. :-|
k
PTGui Support
embedded into the original file, and the sidecar file being outside the
original file?
Joost
Keith Martin
>I guess the idea is to distinguish [...]
Yes, I'm sure that's it. The 'sidecar' name always felt a little
clumsy to me, but it has become fairly standard terminology and I
can't think of a better one anyway. :-)
It is a shame that Adobe's files are too proprietary to be meaningful
outside of ACR, but I guess it isn't that surprising. Back to PTGUi
and its RAW support, a new feature doesn't *have* to be for everyone
for it to be good, eh?
k
PTGui Support
> outside of ACR, but I guess it isn't that surprising.
Probably it would only be meaningful if they disclose the actual
algorithms. I don't blame them for not wanting to do this..
> Back to PTGUi
> and its RAW support, a new feature doesn't *have* to be for everyone
> for it to be good, eh?
Exactly!
Joost
Ken Warner
Roger D. Williams
procedure will be do so as I have been; process the RAW images in
DX0 or Silkypix (very VERY different programs but each good in
their own way) and then bring them into PTgui. See interleaved
comments below. Your command of English is astonishing, by the
way!
On Mon, 26 Jan 2009 17:55:52 +0900, Erik Krause <erik....@gmx.de> wrote:
> Roger D. Williams wrote:
>
>> I have looked at this. This is a plugin for PhotoShop that will work
>> with CS and CS2 (which I have on my home and office computers). So
>> presumably a PS "action" (which I assume is a kind of batch file)
>> would apply the same correction parameters to all the images selected.
>
> Not exactly. PTShift determines the parameters only. They were
> originally meant for the panotools Radial Shift filter which is part of
> the panotools photoshop plugins. BTW.: PTGui has an interface to the
> plugins, too. Just press the "Correct" button on PTGui Source images tab
> (needs panotools to be installed).
>
>> But then I would have had to convert all the RAW to TIFF.
>
> Yes, and that's the downside. Since CA is best corrected in RAW.
Oh well, I suppose that's the clincher.
>> I don't understand what you mean by "transform the parameters" though.
>
> Transformed for dcraw. dcraw wants two parameters. It does a linear
> correction only whereas panotools do a polynomial one (same as lens
> distortion).
>
>> Is it that the PanoTools a, b & c parameters are not the same as the
>> ones that the latest version of PTgui uses?
>
> Yes, they are the same. But in case of CA correction they need to be
> used on separate color channels instead of the same image. That's what
> radial shift filter does.
>
>> I must say that this plug-in seems to offer the most comprehensive
>> approach to compensating for CA.
>
> Yes, they do. Unfortunately they don't work on RAW image data. My dream
> application would be a RAW converter with an interface to radial shift
> filter.
>
> However, I had a discussion with Thomas Niemann (Author of PTLens) about
> linear versus polynomial CA correction and his point was that he didn't
> see a an image where polynomial was really necessary. And he has the
> overview since for PTLens he calibrated a lot of lenses. So may be
> linear correction (what all RAW converters do if they offer CA
> correction) is enough for real world lenses.
>
> PTShift might be a bit of overkill to determine correction parameters
> for dcraw. Perhaps it is enough to use the numbers from your RAW
> converter together with a correction factor. This would be a matter of
> experimenting...
Well, I certinaly find that Silkypix can do a very good job of curing
CA, and of course DX0 is truly excellent with the camera-and-lens
combinations for which it has modules. If it catered for my Sigma
plus D300 I'd probably never bother with anything else.
> On the other hand: Why not do RAW conversion in an external RAW
> converter (including CA correction) and use PTGui where it's main
> strength is - for stitching? Ok, you have those intermediate TIFF files,
> but it should be small effort to delete them once your panorama is
> ready. This can even be automated using a shell script.
>
Yes, I'm convinced. I dpn't have to like it but I see I have to DO
it...
Joergen Geerds
every other RAW developer, for the same thing.
well, it was a thought...
that said, maybe you can implement some CA parameters to be passed
from ptgui to dcraw during opening... maybe specific to some lens info
from the exif
joergen