Ideas and speculation

While working on the indexer I have come up with some wild/weird ideas. 

I notice that Jpeg files can have GPS data embedded in them, and now
have some code to extract this. I have even managed to find one file
with these fields set! There are two Ricoh cameras that can set the GPS
fields automatically, if you plug a GPS card into a slot in the camera -
I am sure this will drop in price and become widespread. 

This opens up the possibility of doing a lot more with Ed's GeoData
backend - and possible the document backend. In principle, if you have
documents that are geo-referenced, when you open and/or view them, you
should emit a lat/long clue, and call up the other stuff from nearby.
Likewise, if the GeoData backend can chain place name clues to latlongs,
other backends can find the nearby images. 

This might actually realise the dream of having the holiday photos pop
up, when you IM about your holiday!

Efficient retrieval of spatial data from large sets needs special
support in the database - products like Oracle SDE (Spatial Data
Extension). The only open source one I know of is PostGIS, which is
layered on top of postgres, using the GIST index feature to implement an
R-tree index for 2-D retrieval.

In a similar vein, I found some art jpegs, which had meaty comments
about the image. The document indexer now finds them if the IM
conversation is (artifically) steered to engravings, iconography and the
like. It would work very well if an app (f-spot maybe?) had an easy way
to add comments and/or categories to images.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]