Support photospheres for photographs and topos

[dldx]

It would be pretty amazing if theCrag had support for 360 degree panoramas, AKA photospheres. Support for creating them has been in Android for sometime now and I think that it would be a very innovative feature for climbing databases.

While many people have taken photospheres while actually climbing, it comes into its own element when used for topos. This is because android phones (and maybe iOS) allow you to view them taking your orientation and tilt into account. This means that you can actually go up to the point where a photosphere topo was taken at a crag, click on the compass icon, point your phone to the crag and have the topo routes virtually overlayed on the rock!

While I haven't looked into the details of this, I believe it should be relatively straightforward to implement into the crag. You could also cheat by simply rendering routes onto the original photosphere image and android will do all the work for you! Here's an example of what I mean. Load it on your android phone, click on the photosphere icon, then on the compass in the bottom left corner :)

[scd]

Looks pretty cool. Brendan can comment on what is missing from our database.

However the biggest issue I see is that our topos need to work across different types of media. In particular print and apps.

If a user is relying on this information to climb at a crag and it is missing from the PDFs it is a bit of a problem. I imagine though, the photoshere can be rendered as a panarama, which can be used on a PDF.

If it was just in the photos section then this can be more advanced specifically for the web.

[brendanheywood]

I've had this thought too, some crag's like KP in brissy have street view photosphere's of the cliff. A brief list of what we'd need in order to make this work:

• [ ] uploading a flattened panorama sphere is nothing special, just need a flag to say it's a sphere
• [ ] when editing a topo you'd need to draw it onto the warped pano, this may not be too bad, but I certainly would not embark on making the topo tool editable while viewing a dynamic photosphere (right now I'm in the middle of a complete rewrite of the topo tool, if it was going to happen, it would happen now - but it won't)
• [ ] when viewing the topo, the simple solution as you suggested is to flatten the topo into a static image and then hand it off to google or some other viewer to turn into a dynamic panable sphere. Having a dynamic panable sphere with hover routes etc, is just in the too hard basket right now, as it is rewriting the topo js client again (but that said this would be much easier after the new topo code is released which has been split apart specifically to make stuff like this much easier). We don't yet have server side rendering on topos yet, but we need this for other reasons so it's coming soonish. Also showing a 360 pano in a PDF would look crap, so we'd probably also want to store for each pano a default direction, tilt, field of view etc so we render out just a 'normal' topo in these cases.

I also have a few concerns about general image quality, we have enough problems with the variable quality of static pics, and more issues with stitched panos, and the general quality I've seen on spheres is even lower with lots of stitching artefacts and dodgy white balance / exposure blending. Over time this will go away, but there are also photo composure issues which won't go away - ie the best topos are not taken close to the cliff but well back.

Related note: I'd love to be able to support zoomable topos like this (and zooming may be supported in the next release or if not shortly after): http://www.yosemite-17-gigapixels.com/ElCapitanZoomify.htm

Other related things we've though about are simply overlaying the drawn topo data onto a live camera feed on a phone, using some augmented reality lib. Would also be very cool.

At the end of the day while I see this as pretty cool, I don't really see them as massively more value than a good quality normal topo, and it is a fair bit of work. So don't hold your breath :)

[dldx]

Well, I agree with everything there! Especially about the image quality - android cameras aren't exactly the best... You can actually create photospheres with standard panorama software, not just android phones, so quality doesn't necessarily have to be an issue. You can also just edit routes using the standard flat image topo editor rather than with the photosphere viewer. I'm guessing that it wouldn't be that straightforward to code otherwise. I'll probably have a go at coding a dynamic viewer if I get some time though.

And finally, while I mentioned 360 degree panoramas, I don't think they're even that useful for climbing. You could easily get away with 120 degree panoramas that still show the whole crag (and then just utilise a portion of that for PDFs). My idea is more to utilise the compass and tilting sensors.

[brendanheywood]

Something else related which is quite close on our radar is adding metadata to normal photo topos of the lat long, direction, azimuth, field of view and focus plane depth, in order to add these nicely to maps and show a little preview field like you often see in guide books but with more interactivity. see #846

Once this metadata is in place it can be leveraged in lots of ways similar to what I think you have in mind. The two easy formats that come to mind are adding this to our kml exports (not sure how much they get used, probably not worth it) and I've always wanted to tinker with making a Layar using their geo layer api which does all the heavy lifting for you to turn it into an augmented reality map https://www.layar.com/

[dldx]

A Layar would be quite cool. I don't use it at the moment but I probably would if it had topo information.

[georg-d]

See also https://github.com/theCrag/website/issues/3459 amout "advanced photos"

[georg-d]

The links of the original post do not work for me any more.

I'd love to see topo panoramas, especially those that can have up to 360°x360° and are navigable/movable (also by gyroscope of a mobile!) as well as zoomable, e.g. a rock wall in Frankenjura or a place in a village. These do not require special hardware - you just have to ensure your camera takes all shots from the same position (e.g. ordinary tripod with ballhead).

Despite liking 3d panos very much because they make you feel you're just "inside the picture" and let you "look around in detail and overview" and also avoid bended lines, I strongly discourage to build that into theCrag:

1. They look poor when "flattened" (i.e. not interactively seeing only a small viewing angle but statically seeing the whole image at once) for PDF etc. so we'd still need classic images - additionally. Will users be contibuting "twice the same" if even topo photos are missing in large scale?

2. While implementation of such a feature is conceptually rather straight forward, it's quite an effort to make it practically work fine on many hardware & software environments - and theCrag user base probably has a big variety. Even when we tackled that, the feature causes considerable maintenance effort (rewrite of a big share of the code) in relatively short intervals of 3-5 years because the technology evolves quickly. For example, for Panorama Studio, 2015 Flash was standard and HTML5 experimental, while 2020 HTML5 was standard and hardware & APIs evolved so much that that gyroscopes were common, causing users to long for this intuitive way of navigation. Instead of putting a lot of dev resources into a fancy but edge feature, I would prefer to see these dev resources improving the core of the website.