Image geometry data into EXIF?

[Klaus]

Hello all,

With crop lines available in the Stitcher tab making cropping in gimp
less urgent, and EXIF being ported as default from original images, I
want to propose to add image geometry info into the image output as
well.

As I do see a vast majority of panoramic images not being of the 4\pi
or 360 degrees type, information like hfov, projection type, position
of horizon line should allow viewer programmes to properly display the
hugin/enblend output.

Is there maybe even a standard way of including such info into EXIF?

Regards

Klaus

[Bruno Postle]

On Sat 10-Jan-2009 at 10:09 -0800, Klaus wrote:
>
>As I do see a vast majority of panoramic images not being of the 4\pi
>or 360 degrees type, information like hfov, projection type, position
>of horizon line should allow viewer programmes to properly display the
>hugin/enblend output.
>
>Is there maybe even a standard way of including such info into EXIF?

Only for rectilinear images, we could add fake focal length and
sensor size info, but this would be wrong if the image is cropped.

PTmender sort-of does what you want, it puts a full copy of the
stitching script in the exif data. We could modify the hugin
exiftool command to do the same, but currently no tools are able to
make use of it.

--
Bruno

[Klaus]

Hi Bruno,

On 11 Jan, 14:32, Bruno Postle <br...@postle.net> wrote:
> On Sat 10-Jan-2009 at 10:09 -0800, Klaus wrote:

> >Is there maybe even a standard way of including such info into EXIF?
>
> Only for rectilinear images, we could add fake focal length and
> sensor size info, but this would be wrong if the image is cropped.

It is this cropping in addition which I think needs to be taken into
account, in particular for cylindrical and equirectangular
projections.

> PTmender sort-of does what you want,

So far I mostly viewed panoramic images with standard viewers. But
when one starts to transfer EXIF to the stitch, when geocoding images
becomes popular, then I feel a little help for viewers might be
appropriate.

> it puts a full copy of the stitching script in the exif data.

This is more than I thought of, fine by me. However, having followed
the story of some proprietary entries by camera makers a few months
ago, I'd suggest that at least within the panoramic software community
one agrees on some kind of standard.

> We could modify the hugin exiftool command to do the same,
> but currently no tools are able to make use of it.

For instance on wikimedia commons there is a viewer for 360 degrees
panoramas, which digests cylindrical projections. For proper display
one has to provide the height of the horizon line. Such info in the
EXIF would avoid guessing it or revisiting the pto file to retrieve
it.

projection: cylindrical
hfov: 123.456 (degrees)
horizon_at: 36 (percent from top edge)

Obviously there would be several ways of giving such info, pixels,
angles, percentages. Maybe the latter because it is still valid after
image scaling, maybe several or all of them?

Regards

Klaus

[Daniel M German]

Klaus twisted the bytes to say:

Klaus> Hello all,

Klaus> With crop lines available in the Stitcher tab making cropping in gimp
Klaus> less urgent, and EXIF being ported as default from original images, I
Klaus> want to propose to add image geometry info into the image output as
Klaus> well.

One thing I have wanted to implement in PTcrop is the ability to
automatically crop the image to remove any area that has no
information. I think Max's PTstitcher implements it already.

--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

[Daniel M German]

Bruno Postle twisted the bytes to say:

Bruno> On Sat 10-Jan-2009 at 10:09 -0800, Klaus wrote:
>>
>> As I do see a vast majority of panoramic images not being of the 4\pi
>> or 360 degrees type, information like hfov, projection type, position
>> of horizon line should allow viewer programmes to properly display the
>> hugin/enblend output.
>>
>> Is there maybe even a standard way of including such info into EXIF?

Bruno> Only for rectilinear images, we could add fake focal length and
Bruno> sensor size info, but this would be wrong if the image is cropped.

Bruno> PTmender sort-of does what you want, it puts a full copy of the
Bruno> stitching script in the exif data. We could modify the hugin
Bruno> exiftool command to do the same, but currently no tools are able to
Bruno> make use of it.

In my opinion the entire script is the best solution with respect to
embedding information about how the stitch is done.

Each of the images that is output by PTmender have this information in
an TIFF field (I don't recall which one, I think it is the TIFF
comment field). The TIFF field that indicates the "page number" and
"total pages" have the corresponding image number from the script. So
you can easily lookup the "i" line that generated that image.

All PT<tools> keep the script in the file. This data is lost in JPegs.

--dmg

[Daniel M German]

Klaus twisted the bytes to say:

>> it puts a full copy of the stitching script in the exif data.

Klaus> This is more than I thought of, fine by me. However, having followed
Klaus> the story of some proprietary entries by camera makers a few months
Klaus> ago, I'd suggest that at least within the panoramic software community
Klaus> one agrees on some kind of standard.

PTstitcher input format is sort of an standard.

But I agree, having a universal format would be good. Another question is,
where do we put it? PT<tools> put it in the TIFF comment field, and
they do not output JPGs.

---dmg

[Bruno Postle]

On Mon 12-Jan-2009 at 15:51 -0500, Daniel M. German wrote:
>
> Bruno> PTmender sort-of does what you want, it puts a full copy of the
> Bruno> stitching script in the exif data. We could modify the hugin
> Bruno> exiftool command to do the same, but currently no tools are able to
> Bruno> make use of it.
>
>In my opinion the entire script is the best solution with respect to
>embedding information about how the stitch is done.

One problem is that the script is usually very compact unless it
has thousands of lines of control points - These are of no interest
in the output image metadata.

--
Bruno

[Klaus]

Hello,

When I wrote my suggestion, I thought about my usual workflow of
stitching and then cropping to rectangular shape, whatever the output
projection. And I had realised the advantage of a proper panorama
viewer over Preview/IrvanView/xv.

Although I did not ask for it, there may indeed be a point in
providing information on image data area inside an image file
(although within TIFFs the mask could prevent the viewer from
venturing into directions without image content). But that is image
content, not projection geometry.

So for a viewer to interpret the projection correctly, for rectilinear
(and fisheye) one needs to tell where the optical axis is in the image
(expressed as a fraction of image width/height from the left/top), and
in some way the focal length (measured in image diagonal length
units). If this info is invariant to image scaling, even better (so it
is). For cylindrical and equirectangular it is about hfov (degrees,
rad, gon?) and the position of the horizon line in the image (from the
top in units of height). In other words, just the info to allow
mapping of the image back onto the panosphere.

Cheers

Klaus

[Daniel M German]

Klaus> Hello,

Klaus> When I wrote my suggestion, I thought about my usual workflow of
Klaus> stitching and then cropping to rectangular shape, whatever the output
Klaus> projection. And I had realised the advantage of a proper panorama
Klaus> viewer over Preview/IrvanView/xv.

Klaus> Although I did not ask for it, there may indeed be a point in
Klaus> providing information on image data area inside an image file
Klaus> (although within TIFFs the mask could prevent the viewer from
Klaus> venturing into directions without image content). But that is image
Klaus> content, not projection geometry.

Klaus> So for a viewer to interpret the projection correctly, for rectilinear
Klaus> (and fisheye) one needs to tell where the optical axis is in the image
Klaus> (expressed as a fraction of image width/height from the left/top), and
Klaus> in some way the focal length (measured in image diagonal length
Klaus> units). If this info is invariant to image scaling, even better (so it
Klaus> is). For cylindrical and equirectangular it is about hfov (degrees,
Klaus> rad, gon?) and the position of the horizon line in the image (from the
Klaus> top in units of height). In other words, just the info to allow
Klaus> mapping of the image back onto the panosphere.

Would it be possible to embed this info with stenography, to the point
that even if the file is modified, it alpha channels removed,
cropped, or resized, that axis is still available?

I can imagine the axis can be stored with 2 points; one more can be
used for "field of view".

It is feasible to embed stenographically 3 points into an image such
that viewers can detect them and interpret them? My intuitions tells
me it should be.

--dmg

[paul womack]

That just seems too evil for words. Many image processing tools
can retain EXIF information, so that would seem preferable.

BugBear

[Daniel M German]

Carl von Einem twisted the bytes to say:

Carl> Hi Daniel,

Carl> that's steganography instead of stenography, right?

Carl> Cheers,
Carl> Carl

Hi Carl,

Oops, you're totally right. I meant steganography.

--dmg