RFC: Better image handling

Dirk Hohndel dirk at hohndel.org
Sat Feb 14 07:37:47 PST 2015


On Sat, Feb 14, 2015 at 11:02:47AM +0100, Robert C. Helling wrote:
> Hi,
> 
> now, after 4.4 is out, might be a good time to improve the way we store images. Here are some thoughts as how to proceed. Before I start coding I would like to hear your comments (and help is of course appreciated).
> 
> Currently, we store a local filename (with absolute path) in an event that represents the image. This is of course not portable when you have several computers where your images reside at different paths. And you also lose your dive-image associations when moving he image files around on the file system. 
> 
> One could try to implement some “image base directory” plus relative path kind of thing but I guess that is quite fragile and becomes complicated at least when different OSes are involved. 
> 
> So my proposal would be the following:
> 
> 1) We keep the file name (and this is how we present a file to the user) but now interpret it as “original file name”.
> 
> 2) Upon successfully loading an image from that path we compute a hash of the image file and store that hash as well with the event (maybe escaped into the filename since there is only a single string).

We can always change the syntax.

Would it make sense to store three strings?

picture-filename
path
hash
 
> 3) We maintain a dictionary (QHash) where the image hashes are the keys and local filenames are the values. That QHash gets loaded at startup and saved upon quit to a local file (and is not dive log specific but refers to a computer or maybe to a user of that computer). What would be file name/location for that file. Is there a per user subsurface directory?

I hadn't thought about making this machine specific. Hmm, that's an
interesting idea. Not sure where we would store this... I guess we could
put it in the default directory? Just like Linus did with the git files.

> 4) We provide a function that scans a directory (and subdirectories) for image files and inserts those to the QHash as well (possibly overriding keys). 
> 
> 5) When loading an image with the original file name fails, we look up the hash in the QHash and load that file instead. We do _not_ check that the hash is correct (as the image might have been edited).

Also interesting logic.

> Combining 4) and 5) one can use the same image files in a totally different directory structure (e.g. keep all images asa back up in a single directory) on a different computer and still display them with the dive.
> 
> 6) Whenever we successfully load an image to display, we compute the hash and insert it in the QHash.

So the QHash will then have possibly multiple hashes for the same image.
Also interesting idea.

> 7) Besides a fileselector for adding new images, the user can also enter a URL. That URL can either relate directly to an image or to an html where we use all <img> tags. If those non-local files match times to be associated to a dive, we download them to a local image cache and add the local path in the cache to the QHash. We use the URL to the image file as “original file name” (possibly with a different event for non-local images). We provide some way to purge that cache.

OK

And yes, I have started using Qt for core functionality where the advanced
data structures help us. There are quite a few such function in
qthelper.cpp for example

/D


More information about the subsurface mailing list