Re: SubSurface Mobile and OTG

2018-05-22 Thread Miika Turkia
This does work for some divecomputers, depending on the ftdi chip that is
used on the cable. We also have some trouble with Android OS as some newer
Android versions prevent us from accessing the USB devices. What versions
of DC, cable (the serial chip), phone and Android you are using? (I have
used OTG on Nexus 7 tablet and Suunto Vyper Air DC successfully, don't
remember the Android version on the tablet.)

On Wed, May 23, 2018 at 8:15 AM, Thomas Fänge 
wrote:

> Hi!
>
> First, thanks all for you effort and the great and useful application!
>
> I'm connecting my dive computer to my Linux laptop, and that works perfect.
> But, wouldn't it be possible to do that on the SubSurface Mobile (Android)
> app too?
>
> I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable to
> use e.g. a mouse or external keyboard, so should it not then be possible to
> use USB-communication from the SubSurface app too, instead of only a
> Bluetooth connection? This would enable me to only bring the phone while
> travelling, even on the boat or shore and download my dives, getting the
> current position etc. without worrying if the phone gets wet or not.
>
> Today, when I connect the dive computer to the phone with the OTG cable, I
> can see on the leds on the interface cable that the connection is made to
> the phone, but that interface (USB) never turns up as an option in the
> SubSurface dive computer menu - only Bluetooth is available there.
>
> Best regards,
> Thomas
>
>
> ___
> subsurface mailing list
> subsurface@subsurface-divelog.org
> http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface
>
>
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Hashing videos

2018-05-22 Thread Berthold Stoeger
Hi Lubomir and Willem,

On Dienstag, 22. Mai 2018 23:06:03 CEST Lubomir I. Ivanov wrote:

> i was thinking about running hashes on the thumbnails but that has a
> couple of problems:

I think generating hashes of thumbnails is out of the question. Not only, as 
you note, may Qt's scaling algorithm change; extracting thumbnails from videos 
is at the moment not even supported. You can have different streams, embedded 
thumbnail(s), and other complexities. This is all very unstable.

> i guess the biggest question here is what are the hashes used for?
> if they are used to skip the generation of thumbnails for already
> existing media, then the above proposal is completely invalid.

Indeed, let's wait for Robert's assessment.
 
> > Or perhaps even remove the hashes? I found three users:
> > 1) In git storage. This is unsupported afaik.
> > 2) The "Find moved images" functionality. Perhaps searching for (case-
> > insensitive?) filenames is enough? Or perhaps match by metadata?
> > 3)  In current head it is also used for the thumbnail files, but this
> > could be changed before doing the next release.
> 
> something like hashing the date/time + metadata is a good option too i
> guess. depends on what we need a hash for.

We wouldn't even have to hash that, as we just store it unhashed. One scheme 
that came to mind (supposing the only point of the hashes is to find moved 
pictures): We consider two pictures as equivalent if
1) They have the same filename (modulo path and case)
2) They have the same length
3) They have the same meta-data in the case of JPEG
Finding two different pictures fulfilling 1-3 must be very bad luck. We 
currently don't store file-length, but that can be trivially rectified when 
opening an old log.

It would not find renamed pictures, but that also sounds like a case of "tough 
luck".

Berthold
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


SubSurface Mobile and OTG

2018-05-22 Thread Thomas Fänge
Hi!

First, thanks all for you effort and the great and useful application!

I'm connecting my dive computer to my Linux laptop, and that works perfect.
But, wouldn't it be possible to do that on the SubSurface Mobile (Android)
app too?

I have a "watertight" Sony phone, and I use a USB On-The-Go (OTG) cable to
use e.g. a mouse or external keyboard, so should it not then be possible to
use USB-communication from the SubSurface app too, instead of only a
Bluetooth connection? This would enable me to only bring the phone while
travelling, even on the boat or shore and download my dives, getting the
current position etc. without worrying if the phone gets wet or not.

Today, when I connect the dive computer to the phone with the OTG cable, I
can see on the leds on the interface cable that the connection is made to
the phone, but that interface (USB) never turns up as an option in the
SubSurface dive computer menu - only Bluetooth is available there.

Best regards,
Thomas
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Re: Hashing videos

2018-05-22 Thread Lubomir I. Ivanov
hello,

i believe Robert should comment on this as he originally wrote the
first implementation of the profile photos.
(CC).

On 22 May 2018 at 23:45, Berthold Stoeger  wrote:
> Dear all,
>
> I'm currently implementing addition of videos to the dive photos. This happens
> to be dog-slow, because we calculate hashes of the file contents. As you can
> imagine, addition of multiple videos with a few GB each is a major CPU hog.
> Granted, the UI stays responsive, since this is done in background threads.
> Nevertheless, it gives a bad impression if the CPUs run at 100% for a few
> minutes.
>
> What are we supposed to do? Hash only the first MB? That would unfortunately
> not be backwards-compatible. Do different things for images and videos? Sounds
> hard to get right.
>

i was thinking about running hashes on the thumbnails but that has a
couple of problems:
1) if Qt changes the backend of the code we use for thumbnail
generation the hashes would stop matching
2) thumbnail generation for videos would need to happen not for the
first frame but rather for an arbitrary point of the video timeline -
e.g. thumbnail at 30% length.
(that's actually a good generic way of doing it, instead of using
always the first frame)
but if two thumbnails for two videos happen to have exactly the same
frame at those 30% of the length (e.g. consider a black screen
transition), we risk generating the same hash for two different videos
for the same frame.

that on the other hand might not be ever possible for compressed
video, as the compression adds noise which would essentially generate
thumbnails with slightly different bytes, unless it's uncompressed RAW
video in which case the thumbnails would match perfectly and therefore
the hashes too.

i would still consider this as an option if we really need hashes and
we want them to be fast.

i guess the biggest question here is what are the hashes used for?
if they are used to skip the generation of thumbnails for already
existing media, then the above proposal is completely invalid.

> Or perhaps even remove the hashes? I found three users:
> 1) In git storage. This is unsupported afaik.
> 2) The "Find moved images" functionality. Perhaps searching for (case-
> insensitive?) filenames is enough? Or perhaps match by metadata?
> 3)  In current head it is also used for the thumbnail files, but this could be
> changed before doing the next release.
>

something like hashing the date/time + metadata is a good option too i guess.
depends on what we need a hash for.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface


Hashing videos

2018-05-22 Thread Berthold Stoeger
Dear all,

I'm currently implementing addition of videos to the dive photos. This happens 
to be dog-slow, because we calculate hashes of the file contents. As you can 
imagine, addition of multiple videos with a few GB each is a major CPU hog. 
Granted, the UI stays responsive, since this is done in background threads. 
Nevertheless, it gives a bad impression if the CPUs run at 100% for a few 
minutes.

What are we supposed to do? Hash only the first MB? That would unfortunately 
not be backwards-compatible. Do different things for images and videos? Sounds 
hard to get right.

Or perhaps even remove the hashes? I found three users:
1) In git storage. This is unsupported afaik.
2) The "Find moved images" functionality. Perhaps searching for (case-
insensitive?) filenames is enough? Or perhaps match by metadata?
3)  In current head it is also used for the thumbnail files, but this could be 
changed before doing the next release.

Ideas?

Berthold
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface