Image management, bug fix

[Guido Lerch]

Hi Robert
Before I comment point by point let me mention that is is exploratory and that I do not have all the answers yet.
Yes I am a photographer and my intent is to have the images available regardless off the computer I am at.
Hence a Dropbox location would do the job. My expectation is that people are not wildly let ssrf manage tons of images unless they provide the space.
Long term I have some really cool features in mind.

Regards,
Guido
+41 79 3217739

> Am 13.10.2015 um 11:49 schrieb Robert Helling <helling at atdotde.de>:
> 
> 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).
Have that fixes already but not submitted based on a note from this group.
> 
> In fact, I could not find the function that does the actual copying. Are you sure your patches are complete?
It works on Mac, I am reusing a copy function that was existing already that does the translation for the copy process
> 
> 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.
Bummer, I missed this and will fix.
The copy is done correctly but the file names will not be stored unless picture handles this, I need to check.
> 
> 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.
In place is tricky too as with the cloud service people might use the app from different computers.
> 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 found this rather confusing, that's why I try something different.
Overall your input is valid and will finally lead into something that the user loves.
Btw the reason I made this configurable is that people that don't like it can use it the "old" way.
> 
> 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.
I keep on playing with this, maybe we'll find something that makes ssrf stronger.
I would not want to use it the current way as only a fraction of my pictures make it into the ssrf dive. The vast majorit sits on a hD that is not accessible from all my computers.
> 
> 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/4520a3dc/attachment.html>