GPS data from jpeg's and more

[Robert C. Helling]

On Fri, 1 Feb 2013, Dirk Hohndel wrote:

Dirk,

> There are good things and bad things about this. I like the idea of
> having a tool to do this - so I guess any implementation is a step in
> the right direction. I can't figure out how to include this in a
> shipping binary distribution (so how / where would this be installed for
> a Windows user? what about the dependencies), but I can see myself
> including this in the sources and possibly providing it over the web.

I admit using it on Windows will require an initial investment of time. Of 
course, there are Windows implementations of Perl. Of course, these are 
huge packages and we don't want to ship a perl environment just to run a 
script. But once you have perl itself everything should be pretty smooth 
as there is a culture of caring about portability of modules. That was 
also a reason of using existing perl modules rather for things like: Here 
is a time, add one hour and three minues to it. Also the mechanism of 
installing additional modules using the cpan binary should work on any 
platform (but I don't have a windows machine at my disposal to actually 
try this).

> Can it take a path and (recursively?) look at all the pictures in that
> path? That would seem like a very useful feature...

At an early point I had this implemented (you can still see the line where 
it worries about a file acutally being a directory). I threw it out again 
as I decided to go with the "simple tools" philosophy: As it accepts any 
number of image files as the last parameters, you can get this behaviour 
with standard command line tools like

find .| grep 'jpe?g' | xargs ./import_data.pl <options>

But adding a recursive descent through a directory tree (possibly with 
maximal depth) requires only a few lines of code if you want that.

I had also thought about doing a similar thing for web pages: Currently 
you can specify remote pictures using a URI. Why not also accept an URL 
for a html document and use all <img>'s linked on that page (the 
application would be your image gallery)? This however requires also 
parsing html, but there is a module for that... One could even follow 
links and then crawl the whole web to look for images containing useful 
gps data. Well, maybe I am getting carried away here.

>
>> For the matching to work, it is quite essential that the camera and
>> your computer (and the dive computer) have roughly the same idea about
>> the current time. I added the possibility to correct for this: To
>> determine the time difference between your camera and your desktop
>> first run
>>
>> ./import_data.pl -t
>>
>> This prints the epoch every second. Now take your camera and take a
>> picture of your screen. Transfer this image to the computer and write
>> down the last time stamp that can be seen on the picture. Then run
>>
>> ./import_data -c <timestamp> <image.jpeg>
>>
>> This will print the offset between the timestamp and the timestamp
>> produced by the camera. You can use this offset as -s option for all
>> other image operations.
>
> Wow. That's elaborate :-)
>
> One thing I wonder about is the XML parsing that you do. How much effort
> is spent on understanding Subsurface's XML file format and keeping it
> intact? Might it be easier to create an XML file in a format similar to
> what we get from the webservice? It would be easy enough to add an
> option to Subsurface to import that file and merge its data with the
> dive log...

I have to admit I have not spent too much time with this. I use the 
XML::TreeBuilder module to parse the xml and then dump it again with with 
as_XML() method. I don't know if that implicitly does any kind of 
transformation that breaks the parsing. With the files I tried I did not 
encounter any problem. What I found it does different than subsurface 
itself is when it adds the image event it adds it as

<event ...></event>

rather than

<event .../>

but subsurface's parser seems to be ok with that. But of course it could 
output a new xml file with dives with just <gps> elements to be merged. 
Would you prefer that (or have that as an option)?

Best
Robert

-- 
.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oOo.oO
Robert C. Helling     Elite Master Course Theoretical and Mathematical Physics
                       Scientific Coordinator
 		      Ludwig Maximilians Universitaet Muenchen, Dept. Physik
print "Just another   Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
     stupid .sig\n";   http://www.atdotde.de