Image management, bug fix

Robert Helling helling at atdotde.de
Tue Oct 13 02:49:27 PDT 2015


Hi Guido,

> On 13.10.2015, at 11:18, Guido Lerch <guido.lerch at gmail.com> wrote:
> 
> <0005-Adding-image-management-fixing-stupid-bug.txt>


here are a few comments on this series of patches (not really in order).

Re this last one: Who tells you that paths never exceed 256 bytes? I would not be so sure about this, in particular given that they can be unicode (Dirk has this test user on Windows who’s name I forget but its some Mörtlí çßråù something but longer). Also not all OSes use / as a path separator (but if you use Qt for file/path operations it gets translated).

In fact, I could not find the function that does the actual copying. Are you sure your patches are complete?

Maybe it also helps to explain the rationale behind the image hashing logic but first I should say, I am not a photographer myself so my experience with all this is in fact limited to test cases.

But I would imagine, if you are really into photography, your image library can easily be several GB, so I wanted to avoid doubling this “copying images into subsurface” (whatever that might mean) but rather use them in place. This also gives the advantage that you can still edit them (as I understand underwater photos all need heavy color and lighting adjustments to be usable) and they would still show up in the latest version in subsurface. (These considerations are of course already invalidated by the fact that the git storage format also stores the images and thus in a sense already solved the problem you are trying to solve).

Of course, one wants to have (at least) potential access to the images on all computers where you run subsurface. And Dropbox (and the like) is indeed a very convenient mechanism for that (which I use as well). But I think, this should be solved in sufficient generality and in particular it should not break when on different machines the Dropbox folders have different paths (for example I have machines where I am robert, I am helling on others and on some others I am even Robert.Helling, let alone different OSes where the path structure is entirely different). I had though if this could be attacked by doing some path translation or symlinking but in the end I decided (for me, your milage might differ) that not attempting that but displaying the images wherever they are is the right approach. And this is done by hashing. There, the user is completely free where in the file system the images can be found, as long as from time to time she points subsurface to a sub-tree that contains images so subsurface can learn the files in that subtree.

Yes, this does not do the copying but I think the current solution is more general than the one you are implementing. Currently, with your workflow, you could import the images from where they are into subsurface and then, if you want copy them (with finder or any other tool) to the dropbox and then on all computers run “Find moved images” and point that to the Dropbox and all your images will appear.

I agree, that this can be confusing (as the user has to understand what is actually happening) and deserves a better UI but I am not good at coming up with such things.

Just my two cents.

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
                      Phone: +49 89 2180-4523  Theresienstr. 39, rm. B339
                      http://www.atdotde.de

Enhance your privacy, use cryptography! My PGP keys have fingerprints
A9D1 A01D 13A5 31FA 6515  BB44 0820 367C 36BC 0C1D    and
DCED 37B6 251C 7861 270D  5613 95C7 9D32 9A8D 9B8F





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151013/59c7bcab/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.subsurface-divelog.org/pipermail/subsurface/attachments/20151013/59c7bcab/attachment.sig>


More information about the subsurface mailing list