Willem,

first of all re recreational planning mode:

This is supposed to be for people who don’t want to do staged decompression but 
who will ask questions like „how much longer can I dive before I get into 
deco?“, in a sense it has the same audience as the PADI wheel/RDP.

So, while the normal planner tries to ascend from the end of the manually added 
waypoints is the shortest time possible, the recreational planner will extend 
the stay at the last depth for a maximal time that will allow to ascend to the 
surface without explicit stops and within amount of gas available. So, in a 
sense, it gives you the non-decompression limit (NDL), but it takes into 
account:

o) saturation from previous dives (planned or logged), so set the day and start 
time appropriately

o) the possible multi-level nature of the manually added waypoints

o) gas choices in manually added part of the dive (but it will not change gases 
during the ascent, it does the computed part of the dive with the gas of the 
last manually added segment).

o) the following parameters: ascent velocities, gradient factors, reserve gas 
(in addition to the amount of gas used by a buddy buddy breathing thru the 
ascent, i.e. the ascent gas is counted twice), rebreather mode (OC/CCR/SCR), 
gas list. (I still want to add greying out of UI elements not used in that 
mode, so it is probably too early to do screen shots).

o) There is the option to add a 3 minute stop at 5m/15ft. This stop is taken 
into account in the gas calculation but not in the ‚non-deco‘ calculation, i.e. 
the diver can skip it and directly proceed to the surface without violating a 
ceiling.

The gas limit is only taken into account if there is valid gas information 
(cylinder volume and non-zero working pressure). So to disable the gas 
calculation (and do a proper NDL calculation) the user should set the tank 
volume to 0 or the initial pressure.

> On 25 Apr 2015, at 14:52, Willem Ferguson <[email protected]> 
> wrote:
> 
> Robert,
> 
> When adding images from the Internet, what type of images can be added (GIF? 
> TIF?). I suspect this is OS-dependent depending on viewer(s) available?

It handles all image types that Qt can read into a QImage, see 
http://doc.qt.io/qt-4.8/qimage.html#reading-and-writing-image-files

> Are the metadata checked (if available) for date-time consistency?

As with images in local files, images are only added to dives if the creation 
time from the exif data matches the dive time plus 30min before and after (but 
there is the possibility to shift times like for local images).

> I suspect Internet-based images can only be added one image at a time and one 
> dive at a time? What happens when more than one dive are selected?

The number of selected dives is not limited (as for local files), the correct 
dive is matched according to exif time,  see above. Currently remote images can 
only be added one at a time. But I hope that very soon, you can also give the 
URL of an html page and it adds all the images in that web page (like a picture 
gallery)

For Dirk: I would have thought that only images taken with a camera (and not 
drawn in a graphics program) have the exif creation date set. So graphical 
elements being associated to dives should not be problematic. I hope. 

The last thing I added since the last release is the possibility to locate 
images via hashes:

In the past, the absolute path to an image was stored in the xml. This of 
course caused problems when you moved around your image files on your hard 
drive or took your xml to a different computer (with different directory 
layout) for example by accessing it via a cloud directory like dropbox (or you 
used the hidden from the user git-save option).

This is now solved by subsurface remembering fingerprints (cryptographic 
hashes) of images it had successfully loaded. With „Hash images“ from the file 
menu, you can point subsurface to a directory and it will (in the background) 
compute all the fingerprints from images in that directory and its 
subdirectories (this can take a while). These are stored locally (so are 
persistent between runs) and subsurface can display those images in dives if it 
recognises the fingerprint even when the path is entirely different.

In more detail: The fingerprints for pictures in dives are saved whenever the 
dive is saved. So for pictures in old dives, the user needs to save those 
again, to add the fingerprint information.

Then, when on a new computer (or after moving image files around), let 
subsurface hash your image directories and the images should appear.

The saved filename is always first tried, before falling back to the finger 
prints. And even on the other computer, the image file can be modified. 
Subsurface will then learn the new fingerprint and will update the dive 
accordingly.

Actually, when I say filename above, it can as well be a URL. In that case, the 
image is added to a local cache and the local copy is hashed and displayed.

I hope this was not too confusing, but I think it can be quite powerful.

Best
Robert
_______________________________________________
subsurface mailing list
[email protected]
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Reply via email to