Something wrong with exif data processing

57 views
Skip to first unread message

AlekseyM

unread,
May 18, 2012, 8:12:26 AM5/18/12
to hugin and other free panoramic software
I checked out Raw Photo Processor (RPP) recently and found that Hugin
cannot understand some of it's exif data. When I try to load the file,
produced by RPP (either tiff or jpeg) it always asks me to enter
multiplier, which on the Lens screen is called "crop factor". When I
convert the same image with Canon DPP, this does not happen. I tried
to evaluate the difference between exif data in the file, produced by
RPP and the one, produced by DPP and was not able to find any clue why
this may happen. There are some differences, but the data is
surprisingly similar. Yet, there is something wrong. I am starting to
think that the problem may be in the way Hugin treats exif data. Any
ideas? Where I can see how this data is processed by Hugin?

Greg 'groggy' Lehey

unread,
May 18, 2012, 11:03:08 PM5/18/12
to hugi...@googlegroups.com
I had a similar problem with Olympus DSLRs some time ago, and tracked
it down to the file src/hugin_base/panodata/SrcPanoImage.cpp .
Depending on the camera, there are various ways to determine the crop
factor. Take a look and see if you can work out what path your
camera's data goes through. Potentially hugin can be patched to work
around the RPP issue; otherwise you could run exiftool to reinstate
the necessary information.

Greg
--
Sent from my desktop computer
Finger gr...@FreeBSD.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed. If your Microsoft MUA reports
problems, please read http://tinyurl.com/broken-mua

Gnome Nomad

unread,
May 19, 2012, 3:57:30 AM5/19/12
to hugi...@googlegroups.com
On 05/18/2012 05:03 PM, Greg 'groggy' Lehey wrote:
> On Friday, 18 May 2012 at 5:12:26 -0700, AlekseyM wrote:
>> I checked out Raw Photo Processor (RPP) recently and found that Hugin
>> cannot understand some of it's exif data. When I try to load the file,
>> produced by RPP (either tiff or jpeg) it always asks me to enter
>> multiplier, which on the Lens screen is called "crop factor". When I
>> convert the same image with Canon DPP, this does not happen. I tried
>> to evaluate the difference between exif data in the file, produced by
>> RPP and the one, produced by DPP and was not able to find any clue why
>> this may happen. There are some differences, but the data is
>> surprisingly similar. Yet, there is something wrong. I am starting to
>> think that the problem may be in the way Hugin treats exif data. Any
>> ideas? Where I can see how this data is processed by Hugin?
>
> I had a similar problem with Olympus DSLRs some time ago, and tracked
> it down to the file src/hugin_base/panodata/SrcPanoImage.cpp .
> Depending on the camera, there are various ways to determine the crop
> factor. Take a look and see if you can work out what path your
> camera's data goes through. Potentially hugin can be patched to work
> around the RPP issue; otherwise you could run exiftool to reinstate
> the necessary information.

Sounds to me like the problem isn't how Hugin is treating EXIF data, but
how Raw Photo Processor *isn't* putting out the EXIF data properly ... I
use a Minolta 7D, can only say that when I convert a Minolta RAW file
using Bibble, *sometimes* I get a JPG that is missing some or all of the
EXIF data. This only happens when Bibble's image cache has gotten
corrupted. If I clear Bibble's cache so it rereads the RAW file, then
save it as a JPG, it comes out fine.

Maybe RPP has some similar problem?

--
Gnome Nomad
gnome...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

AlekseyM

unread,
Jun 2, 2012, 7:26:29 AM6/2/12
to hugin and other free panoramic software
Greg, Thank you very much. I was able to trace the problem down. Here
is how Hugin calculates the crop factor:

cropFactor = sqrt(36.0*36.0+24.0*24.0) /
sqrt(sensorSize.x*sensorSize.x + sensorSize.y*sensorSize.y);

The sensor sizes are coming from these tags:

Image Width : 3648
Image Height : 2736
Focal Plane X Resolution : 12493.15068
Focal Plane Y Resolution : 12493.15068
Focal Plane Resolution Unit : inches

And here is what RPP produces:

Exif Image Width : 1842
Exif Image Height : 1380
Focal Plane Resolution Unit : inches
Focal Plane X Resolution : 12493.1506849315
Focal Plane Y Resolution : 12493.1506849315

When I shortened the resolution value using exiftool, Hugin started
appreciating the data, but still calculating crop factor incorrectly
because I modified the image size during conversion. I think I can fix
the resolution conversion function, but I am not sure what to do with
the original image size. I think there should be a more reliable
method to calculate the crop factor.

Aeksey

On May 19, 7:03 am, Greg 'groggy' Lehey <groog...@gmail.com> wrote:
> On Friday, 18 May 2012 at  5:12:26 -0700, AlekseyM wrote:
> > I checked out Raw Photo Processor (RPP) recently and found that Hugin
> > cannot understand some of it's exif data. When I try to load the file,
> > produced by RPP (either tiff or jpeg) it always asks me to enter
> > multiplier, which on the Lens screen is called "crop factor". When I
> > convert the same image with Canon DPP, this does not happen. I tried
> > to evaluate the difference between exif data in the file, produced by
> > RPP and the one, produced by DPP and was not able to find any clue why
> > this may happen. There are some differences, but the data is
> > surprisingly similar. Yet, there is something wrong. I am starting to
> > think that the problem may be in the way Hugin treats exif data. Any
> > ideas? Where I can see how this data is processed by Hugin?
>
> I had a similar problem with Olympus DSLRs some time ago, and tracked
> it down to the file src/hugin_base/panodata/SrcPanoImage.cpp .
> Depending on the camera, there are various ways to determine the crop
> factor.  Take a look and see if you can work out what path your
> camera's data goes through.  Potentially hugin can be patched to work
> around the RPP issue; otherwise you could run exiftool to reinstate
> the necessary information.
>
> Greg
> --
> Sent from my desktop computer
> Finger g...@FreeBSD.org for PGP public key.
> See complete headers for address and phone numbers.
> This message is digitally signed.  If your Microsoft MUA reports
> problems, please readhttp://tinyurl.com/broken-mua
>
>  application_pgp-signature_part
> < 1KViewDownload
Reply all
Reply to author
Forward
0 new messages