Right now APP writes a fairly boring caption into the panos it creates, Something of the form "Kolor stitching | 4 pictures | Size: 7029 x 5874 | Lens: Standard | RMS: 3.20 | FOV: 73.31 x 63.72 ~ -1.32 | Projection: Planar | Color: None |" which is useful for diagnostics, but not what most people would like displayed by photo display tools as the caption of the photo.
I would ask that krpano import anything it can find from the source images and propagate them to the pano. From the first source to have a caption if there is a conflict. In addition, it might not be too bad if some key fields could be edited in APP and written into the rendered image exif, as well as stored in the dot-pano file for further editing.
krpano already propagates the geotag from the first photo which is gone, so this should not be a big change.
Other tags to propagate include:
Title Image Description Artist Copyright User Comment Description Caption-Abstract Comment City, Country (and a variety of other geo-explained codes)
You can leave the stitching information in one of the lesser of these, but that would require a bit of a survey of different image programs and what tags they use. Sadly the reason there are so many is that different programs like to use different tags as the caption. Only a few programs independently set the Title. Usually Comment, User Comment, Description and Image Description are the caption.
One can put captions on the rendered results but without this feature, they are erased on re-rendering
Hmm. So what am I doing wrong? For my test, I took the first image (only) and added a variety of caption and title tags such as these:
Image Description : Monument at Place de la Bastille, where a remnant of the prison sits User Comment : Monument at Place de la Bastille, where a remnant of the prison sits Title : The Bastille Description : Monument at Place de la Bastille, where a remnant of the prison sits Object Name : The Bastille Caption-Abstract : Monument at Place de la Bastille, where a remnant of the prison sits Comment : Monument at Place de la Bastille, where a remnant of the prison sits
None of them propagated through to the resulting rendered pano. Do I need to put the caption on every single image to make it propagate through? How does it choose which image to get tags from that propagate? Having to tag every image defeats the purpose of this functionality, we want it to be easy to assign such tags on our panos that persist from render to render. A possible correct action, if there are multple different versions of an exif tag on the source images would be to either take the first -- though "first" can be hard to be exact about -- or perhaps take the longest. Certainly if all but one are null, take the one that is not null.
In addition, as I noted, the renderer puts the stitching data in the user comment, even though I had an image with a different user comment.
As noted, perhaps an ideal behaviour (though it requires more code) is:
a) Examine source images for various freeform text tags. If all are the same, take that. If they differ, take the longest. b) Store that resulting value in the .pano file and keep it as a user editable parameter. Flag it as user-edited or auto-generated. c) Have a UI to let the user see what APP extracted and change it. If they change it, it now overrides what APP extracts, even if the underlying image captions change.
However, lesser UIs are certainly suitable.
Last edited by bradtem on Fri Oct 12, 2012 4:31 pm, edited 1 time in total.
The right UI is a bit hard to decide. After all, it seems odd to caption just one image of a panorama collection, though that's probably the easiest UI to set up. Because I often shoot overlaps and duplciates, I also find myself sometimes deleting images here and there when assembling a pano,so I would have to take care to caption only an image that will not be deleted. And I may find myself adding captions after -- sometimes I assemble panoramas, and then decide the panorama is not good enough and don't publish it, and I only caption and geotag the ones that are published.