Commons talk:Project to create spherical panoramas of important monuments

Project to foster the creation of spherical panoramas (thread moved from Commons talk:Featured picture candidates

Hi, hopefully this is not considered spam...After having had some discussions with a few chapters and some photographers, I have finally put together the idea on a page that I would like to share with you: Commons:Project to create spherical panoramas of important monuments. Why this? we illustrate today our articles with a few photographs, some better than others, but IMHO we are not putting the required attention to the possibilites of spherical panoramas, especially when it comes to document building interiors. We don't have many of these full spherical panoramas and the tools to view them can also be improved by the WMF (not planned so far, though, I already asked Fabrice and Gilles of the WMF multimedia team). Maybe we are in a kind of endless loop now: since we don't have many of them, tools are not needed and since tools are not there this kind of photographs are neglected. I am convinced, though, that rather sooner than latter this kind of media will be expected since there is no better way to provide to a viewer with a more interactive way to discover a place. The project idea is fresh, so there is a lot of room for discussion or even drop the idea if there is not interest in Commons. Please, drop a line there with your thoughts. Poco² 10:59, 18 December 2014 (UTC)

Great initiative! I'd say "let's get a bunch of Ricoh Thetas for when shooting a DSLR is not possible/appropriate", but it's quite expensive for what it can do atm. Maybe in a few years … --El Grafo (talk) 12:11, 18 December 2014 (UTC)

Hi El Grafo, that's really interesting! I didn't know that there are cameras dedicated to this type of shots. That means that given that we have an enhanced viewer in the WM projects and give it visibility for a little money we could find or foster photographers of spherical panoramas Poco² 13:10, 20 December 2014 (UTC)

@Poco a poco: There's also the Panono (previously just called the Throwable Panoramic Ball Camera) but that's about twice as expensive … If the Theta were about 100€ cheaper I'd really be tempted to give it a try. But if Rico's idea of it as the ultimate selfie machine takes off and 360° cameras take the same route as those Action Cams did during the last few years, it might not be too long until we consider "flat" photographs just as outdated as black&white film ;-) Well, we'll see … --El Grafo (talk) 15:58, 8 January 2015 (UTC)

Looks like there are actually some more options around or at least in the making: 360cam (not available yet, only 300° in the vertical direction), bubl (available for pre-order, about $700), iSTAR (kind of professional, around $5000). --El Grafo (talk) 16:23, 8 January 2015 (UTC)

These cameras are not capable of generating the kind of results that I think we would expect though. For a $5000 camera, the iSTAR's image quality looks fairly terrible. And with any of these automated tools, you have little control over when each of the frames is taken. It's important to have manual control because in most situations, there will be people walking around. You will want to minimise the number of people walking around because they will almost always cause problems for stitching. In the case of the iSTAR, there are only 4 cameras with (I assume) very minimal overlap so the resolution is both very low and with no ability to mask out anything, and there is a fairly large nadir gap, which is not a huge problem but not ideal either. These tools are fine when all you need is a basic 360 degree capture but they would not stand up to scrutiny on Commons IMO. Diliff (talk) 10:18, 9 January 2015 (UTC)

I totally agree to all of that, just saying that "consumer" options are coming up and we may want to be able to provide the technical backend soon-ish if (!) people are starting to use them more often. --El Grafo (talk) 10:51, 9 January 2015 (UTC)

Spherical images look very strange if they are not viewed in panoviewer

I like the idea and the initiative, but I see a few practical limits. Firstly and foremost I do not think that Diliff-style interior panoramas and sphericals have many synergies beyond the tools and processing skills needed. Even with a 18mm lens on FX it takes me 20+ shots to get a good view in 360° (4 top 9 upper 9 lower 4 bottom) and going HDR will only make it worse (I know you are supposed to do it with 16mm fisheyes, but I hate fisheyes and don't want to get a lens that has no other purpose than that :D)... Shooting 360° with 35mm or 50mm would be brutal, even though of course the quality would be awesome. If we can get a simple way to implement such images in articles (not having to deal with allowing java every time, long waiting times, tiny window for viewer) I would consider doing such images more seriously, but right now I feel they are a bit gimmicky. I get that it is a bit of a vicious circle with images and viewers but still...--DXR (talk) 12:47, 18 December 2014 (UTC)

Well, I see your point DXR but we are in a similar dilemma of electric cars and missing loading stations. The goal would be to boast the amount of ressources and put them in significant articles to give to this topic visibility. The need to improve the tools will come next. Btw, as El Grafo said, there are cheap ways to arrange spherical paranoramas (quality will not be high, though), but my intention here is indeed to use something like 35 mm to create the pano. That is, of course, a personal choice. If not us, who will provide in the project with some high quality content? I know that it takes time and the post-processing will be long, but still, I believe that a good spherical panorama of, e.g. the Cologne Cathedral, would be more valuable than 20 FPs. Poco² 13:10, 20 December 2014 (UTC)

I think 24mm is max. You mentioned my sample image in Rouen on my talk page and that was taken at 18mm and gives good 110 MP with a high-res camera like a D800. Ballparking a 35mm, I think we should expect at least 300+MP out of that and probably 200+ photos for one HDR-Pano. If we get a place for two hours, we can try that, but imo it is excessive. --DXR (talk) 14:26, 20 December 2014 (UTC)

Daniel, how long did you need to take the picture (rather 4/9/9/1, 23 pictures in total) and to process them?. You mentioned 110 MP, but the uploaded file has a size of 30 MB, did you reduced quality or size? Poco² 15:57, 20 December 2014 (UTC)

I don't know exactly, but not much more than five minutes, surely. Processing takes 10 mins of human time and perhaps 10-15 in hugin for big resolution files. I think the Panorama is saved at Jpeg quality 90, so nothing extrordinary done to size or quality. --DXR (talk) 16:11, 20 December 2014 (UTC)

360° with 35mm or 50mm, OMG!!!, I've been thinking divide the work (reminding the production, manufacturing of automobiles Ford), some people choose to photograph taken and the location and permits, some people take photos, other editing shadows and luminosity, others the unified, others eliminate problems binding and subsequently nominated jointly citing all authors. Maybe this can be a utopia, mainly because photographers are not very open to sharing their work. However, this is only a proposal that would greatly improve the quality, would save time and especially, I would not have to upload images in black and white. --The Photographer (talk) 13:00, 18 December 2014 (UTC)

Wilfredo: that is actually the intention here, dividing the work. I believe and hope that the local chapters can arrange a photography session in significant places and cover the transportation (or even accommodation) costs and we can focus on taking the pictures and processing them. Poco² 13:10, 20 December 2014 (UTC)

No problem with sharing raw files, but completely impractical, at least if you are sitting in a German village with slow internet (that would be me)... --DXR (talk) 13:06, 18 December 2014 (UTC)

I think the 35/50mm bit is a mistake surely -- perhaps with one of those robotic heads and JPG but not by hand or HDR. I have a fisheye and would try this for Commons if there was software to run it. I tried the link using Dschwen's viewer but it won't run due to Java (in)security. -- Colin (talk) 16:21, 18 December 2014 (UTC)

I think for it to really take off, it would need to be fundamentally integrated into the browser experience on Commons/Wikipedia. That will take a lot more work, I suppose. But as Poco says, it's a chicken-egg situation. I'd be happy to take some 360x180 but DXR is absolutely right, there isn't much in common between the high res rectilinear images that I typically produce and a real immersive equirectangular image. It's mainly the focal length and detail. Yes, we'll be able to get a full view in any direction, but the detail will never be equivalent (not practically anyway). Even the detail in my images takes a good 15 minutes of shooting in HDR. To get a 360x180 panorama would take 4-5 times as long. A fisheye or ultrawide rectilinear lens like the Samyang 14mm is the only real choice to get it done in a reasonable timeframe. Diliff (talk) 16:32, 18 December 2014 (UTC)

David, Why that lens in particular?. I see your point about time, but I am not sure whether the time is the main constraint (maybe rather processing time on the PC, not sure). If you all believe that 35 mm is a crazy option we can focus for now on equipment/focal length that wouldn't require too long to take and process the picture, but from the other side I wonder whether the effort to arrange meetings in those places by the chapters would be balanced for a 15 minutes photography session. Poco² 13:10, 20 December 2014 (UTC)

That lens in particular because it is cheap, sharp and ultrawide. It is a slightly more practical lens than a fisheye because it is (nearly) rectilinear. It isn't quite as wide as the widest fisheye lenses, but it's wide enough that a 360x180 panorama will not require too many images. 35mm is slightly crazy. I don't know exactly how many images would be required but I would guess it would be around 40-50, and thats without HDR. If you wanted to bracket with 3 or 5 images, then it becomes 150-200 images. I don't really understand what you're suggesting though. A meeting of photographers from different countries in a single location? What would be the benefit of that? It wouldn't be possible for us all to shoot at the same time in the same room. I assumed you wanted to get a group of photographers in different countries so that we could cover a greater number of subjects in those respective countries. Diliff (talk) 18:14, 20 December 2014 (UTC)

David: I thought the idea was clear, we need involvement of both, photographers and chapters for the same region. What "same region" means I cannot say at the moment, could be England, France, Spain,.... none of them or just a few. If there is a couple of photographers ready to help out in England then we should talk to that chapter. I will try to improve the redaction of the main page. Poco² 18:41, 20 December 2014 (UTC) PD: I will look closer that lens you talk about.

Guys, would you mind if I copy this thread to the talk page of the project page and we close thed discussion at this place? Poco² 19:08, 18 December 2014 (UTC)

I'm happy for you to move it. Diliff (talk) 19:58, 18 December 2014 (UTC)

If it takes too long to take the photo then you will have problems with light changing. Have you found examples on external websites of the sort of image you'd like to get? While a 360 where one can zoom in would be nice, if one merely wants to replicate "being there" then all we need is screen resolution that can be spun round about. Wouldn't details be better captured by single images? And some buildings may benefit from taking the 360 in several locations. -- Colin (talk) 15:46, 20 December 2014 (UTC)

To mitigate the changing light problem you can perform the 360 vertically instead of horizontally, so I hope that neighbouring frames don'd suffer from very different lighting, but that's probably more work. Anyhow, I think that according to the feedback here, the captures from one spot should not be longer than 30 minutes.

To your question about an example from an external website, I've no example yet, since I'm in the process to understand what makes sense and what doesn't. The file size, for example, is IMO a very important constraint, which will probably be the threshold for the quality. I think that a file should not be bigger than 50 MB, but I am not sure if 360 pano viewers need the picture to be fully downloaded first or this happens during the navigation. I also wonder whether the wohle size of a detailed 360 pano needs to be downloaded or this is only required if the zoom-in function is needed. In other words, if a file contains lots of detail (and therefore the size could be 150 MB) but this can only be preceived after zooming in, maybe a viewer who does not zoom in does not need to download the whole file and comes along with 40 MB. I've no clue about these topics, but they are actually importante, since not only countries with a well developed Internet conection should benefit from this. Poco² 16:24, 20 December 2014 (UTC)

There is no reason why the filesize would be greater than 50mb. Most 360x180 degree panoramas are not much larger in resolution than my panoramas. They often don't even contain more frames, they just use a shorter focal length so that the same number of images can cover the full 360x180 range. In any case, I'm not that up to date with cutting edge panoramic technology but in the past (last time I looked into them a few years ago), some panoramas (particularly gigapixel images) were broken up into blocks so that they are loaded progressively. In other words, when first view the pano, you are viewing a low resolution version of it, and if you decide to zoom in on a particular region, it will load the high resolution blocks that correspond to that region. So rather than loading the entire high res panorama all at once before you can view it, it would, in effect, load it 'on demand'. Whether that is still the way modern panoramas such as those on Google Views are constructed, I'm not sure. I think we need to have an idea of the technology that we'd be using to view the images before we can be definitive about what 'kind' of panoramas we'd be able to create. Diliff (talk) 18:14, 20 December 2014 (UTC)

Hey everybody, late but here I am ... creating VR panoramas since a view years. Here an example from LTU-Arena, Düsseldorf, Germany. 10 Pictures, 2 on top, 2 on bottom side and 6 in the middle by using a Nikon D700 with 16 mm fisheye. It takes around 2 minutes to take all pictures. This example is using QuickTime. Would be great to have way here to get those Panoramas working. Zoom in and out using shift or crtl, use the mouse to go around. Regarding the lights: switch to manual mode and get the correct lights for one point to start and go around. Please, contact me if you have any question - I'm having a lot of experience in this area. --Michael Kramer (talk) 09:34, 21 December 2014 (UTC)

• Hi Michael, Yes, with a wide angle fisheye, very few images are needed. The Quicktime example you provided seems to be very low resolution though. There isn't much detail if you zoom in. I think what we need to do is balance the need for good detail with the need to complete the panorama in a reasonable timeframe. The focal lengths you suggested are right though I think. 15-30mm is about right, but there aren't any 30mm lenses for full frame. I think a good idea would be a 28mm lens. Canon makes a decent 28mm prime lens, either a f/1.8 or f/2.8 IS. One thing that should be considered is that not only will you need more images when you use a larger focal length, but each image will likely take longer to shoot because you need to stop down the aperture more in order to retain depth of field. At 50mm, I need to use a minimum of f/13 for depth of field reasons and this results in a very slow shooting time. In many dark interiors, a 0EV exposure might be 10-15 seconds or more at ISO 200. A 24-28mm lens might only need f/8 for the same DOF which would mean less frames required AND less lengthy exposures. Diliff (talk) 12:03, 21 December 2014 (UTC)
• Also, I've managed to find a Panorama Calculator that determines the number of total frames required for a 360x180 panorama (not just horizontal 360 degrees as most panorama calculators do). This is what I've found (assuming a 5D Mk iii full frame camera):
  • 14mm rectilinear: 12 shots and 98 megapixels (two rows of 5 and a zenith and nadir)
  • 16mm rectilinear: 14 shots and 128 megapixels (two rows of 6 and a zenith and nadir)
  • 24mm rectilinear: 24 shots and 289 megapixels (one central row of 8, two rows of 7 and a zenith and nadir)
  • 28mm rectilinear: 27 shots and 394 megapixels (one central row of 9, two rows of 8 and a zenith and nadir)
  • 35mm rectilinear: 42 shots and 616 megapixels (two central rows of 11, two rows of 9 and a zenith and nadir)
  • 50mm rectilinear: 58 shots 1.2 gigapixels (one central row of 16, two rows of 15, two rows of 10 and a zenith and nadir)
• So you can see that it quickly gets out of hand as you approach the larger focal lengths. And becomes quite a bit more complicated to get the most efficient rotations on the panoramic head. It assumes a roughly 25-33% overlap between frames. Diliff (talk) 12:47, 21 December 2014 (UTC)

Hey Diliff, you are right, this example was made for fast impression by internet with 70 % of quality. The 100 % solution would take more time for loading.

I've started in 2006 with a Nikon D300 and 22 mm, that have been 80 pictures for on panorama. Than I've switch to D700 fullframe and 16 mm fisheye (180 degree view), 10 pictures and I will try to go down to 6. I will have a try on this.

the more pixels you got the file will become bigger and loading will take some time.

Would be great to start this project in 2015, starting with some local workshops to get some more photographers involved. I will be with you. --Michael Kramer (talk) 13:01, 21 December 2014 (UTC)

Pinging...

...some other people that could be interested in this topic: @Hubertl: , @Raimund Liebert (WMAT): , @Montgomery: , @Esby: , @Heuschrecke: , @Millars: , @Fedaro: , @Dschwen: , @Böhringer: , @Ximonic: greetings to all! Poco² 13:55, 20 December 2014 (UTC)

2015 has started - let's start the project

Hey everybody.

This is realy a great idea to start some kind of WLM with spherical panoramas of important monuments!

Does somebody has started to get in contact with the local chapter? I'll have a try for the german speaking area to request budget and support. Therefor it would be a good idea, to put your area into your statement so we can start this request together, maybe with local contact people from the project team here.

If we will focus on WLM we should get in contact with the found of this project to get support as well.

Let's have a try! --Michael Kramer (talk) 13:04, 5 January 2015 (UTC)

How is the steps to follow if in my country there arent chapter or user group? --The Photographer (talk) 13:06, 5 January 2015 (UTC)

Hey The Photographer, maybe have a try to check out Wikimedia Community User Group Brasil, have a try. --Michael Kramer (talk) 13:00, 8 January 2015 (UTC)

Thanks for your fast feed back, and Yes!!, you will find my signature on that page, however, that group is inactive. BTW, Happy new year --The Photographer (talk) 13:02, 8 January 2015 (UTC)

Well *smile* in that case you should send a request to the Wikimedia Foundation because they ar in charge for any country without a chapter. --Michael Kramer (talk) 14:50, 8 January 2015 (UTC)

:D --The Photographer (talk) 16:23, 8 January 2015 (UTC)

• I think the most serious limiting factor is still the fact that we have no way to natively view panoramas on the Wiki projects. Have we made any contact with someone who could code a spherical pano viewer for us? I had a go at a church interior panorama yesterday and it was quite successful, technically speaking, but I had to host it on 360Cities to make it web-viewable. I apparently am not even allowed to link to 360Cities as it seems to be a blacklisted site, so the address is https://www.360<remove this>cities.net/image/st-mary-abchurch-interior-the-world here. I'm keen to take more but my enthusiasm is limited by how we can use the images on Commons... Any news Poco? Diliff (talk) 22:00, 2 April 2015 (UTC)

Thanks for the ping and for sharing that nice pano, David. I did contact the multimedia team of the WMF and asked them whether they had considered or would consider the inclusion of a spherical pano viewer in the upcoming releases of the development team and the answer was no. They were aware of the benefit that this feature would mean for the movement, but also mentioned that there were other topics in the backlog that had higher priority. I have been looking for some viewers and found this one, which could be an interested option for the WMF. It does not require any plugins and runs quite smoothly in a new window. Furthermore it is free for non-profit websites but they expect that their logo is placed near the link, so maybe it is worth asking them.

If we don't have an advanced embedded brower in the Mediawiki software we have no other solution for now that doing what you did in 360cities. There are different ways to do it, and I was thinking of something like this (see the globe below your image). Having a logo for this kind of pictures would help to recognize it all over the projects. We could include such a link in the caption of other pictures or as standalone or even in some templates of monuments or natural sites. Btw, you are right, 360cities is in the global blacklist (cannot say why), but still seems to work in the Spanish Wikipedia. I think that that site is pretty popular but there are some other alternatives. What I liked most so far is this site for several reasons: it is free, the viewer works quite good, you can link directly a pano (e.g. this one) and there is no publicity (that is not the case in 360cities).

During my Christmas vacation I also created some spherical panoramas (1 frame every 30 degrees, makes 12 for one ring x 3 rings + one at the top and bottom: 38 different position and depending on the lighting I took 3 or 5 pictures at each position resulting in 114 or 190 frames total) that will upload soon (I have got really no time since beginning of the year). To be honest, I am pretty happy with the result, so I will keep doing it as oft as I can.

Regarding the initiative of this project I have to apologize since I have got no time at all to take care of this so far, and right now I have also a limitation due to the fact that I haven't got a new camera yet. Poco² 17:58, 3 April 2015 (UTC)

It is very cruel of you to tell us this photo without upload in any place. --The_Photographer (talk) 21:57, 3 April 2015 (UTC)

Will come soon, The_Photographer, sorry, I didn't want to be cruel! :) Poco² 08:11, 4 April 2015 (UTC)

Poco, as a small update for this project, I met up with Michael Maggs (the chairperson of Wikimedia UK) last month and told him about our struggles to get these panoramas viewable on Wiki and he agreed it was a good idea and worth pursuing. He said he would raise the issue at the Berlin Wikimedia conference which is happening right now. I don't know whether anything will come from it, but he was positive. He also said that there are big changes happening in the WMF leadership and there is a push to modernise with more Web 2.0 functionality. So all these things could be positive for our project and maybe it will change their plans for the support of these panoramas. I've started uploading a few equirectangular images to Commons with Category:Equirectangular projection and I still have some more left to upload. Perhaps there is a friendlier category name out there but this was the one I found. Anyway, I thought it couldn't hurt to have more high quality equirectangular images on Commons at least to show what we are capable of. Have you made any of your own yet? Diliff (talk) 12:56, 14 May 2015 (UTC)

Thanks Diliff for those arrangements. I have also let some other people now about this topic who are attending the event. The category looks fine to me, and thanks for those uploads! Over Christmas I made also a couple, but haven't uploaded them yet, will do it in the next 2-3 weeks. I agree, we need to show the potential or this and the capabilities of the volunteers within the movement. Poco² 18:43, 14 May 2015 (UTC)

Hopefully between us, we'll have some success from our lobbying then! As for the category, I since found that there's other 'duplicate' categories: Category:Spherical panoramics which contain full 360x180 panoramas, and a parent category Category:360 panoramics which do not have a nadir and zenith. I don't think the quality of them are particularly high though, and most still have the tripod and panoramic head visible in the nadir. It's usually tricky to remove this nadir properly (I still have some troubles with it), but I wonder if it would be appropriate to replace the tripod obscured parts with a Wiki logo patch or something. ;-) I just tried it as a test with DXR's image linked above and it actually works quite well, because the logo has transparency. Diliff (talk) 19:18, 14 May 2015 (UTC)

Diliff No logos, please! ;) I am quite happy with my technic to remove the nadir. I was going to explain it but you can also watch this short video, I guess, that is gonna be quicker :) Btw, regarding WikiCon I am discussing the topic with Kadellar real-time Poco² 12:01, 15 May 2015 (UTC)

I know how to shoot or remove the nadir and I don't have any major problems with it. I was talking about the existing images on Commons by other people that have the tripod visible in the nadir which we have to either leave there (quite ugly and spoils the sense of full 360x180 degree visbility) , or find a way to patch aesthetically. Diliff (talk) 12:39, 15 May 2015 (UTC)

Just to clarify, some of the problems I have with the nadir are complex and not easily solved by the above video. Also, tilting the tripod forward like that is not easy with a heavy tripod, pano head and camera! I wouldn't feel very comfortable doing it with my set up - the camera, ball head, pano head and lens weighs about 4kg, and relying on my foot not slipping off the tripod foot would worry me!. Also, if you are positioned in an area with not much texture on the ground, or it is not flat, it will be very difficult to stitch the nadir properly because you are shifting the position of the camera slightly when you move it and then tilt it down and that will introduce parallax problems. Also, I've occasionally had problems with a bright source of light creating a shadow of the tripod on the scene. It's really difficult to remove that, and if you move the tripod for the nadir, the shadow of it will move, which cannot be blended. I use a slightly different technique to shoot the nadir, compared to the video. I don't lean the tripod forward and shoot the nadir leaning over the pano head. Instead I move the tripod about 1.5 metres away from the point where I shot the rest of the images, and point the camera down at a 45 degree angle. Normally, this would not stitch properly because there would be a huge shift in perspective. But PTGui has a 'viewpoint correction' option. You can set 'viewpoint correction' on this nadir image, and it will not assume it was taken from the same position as the others. It will distort this image differently to the others. You would have to remove any control points that are not on the surface of the floor though, because it can only correct the viewpoint of the flat 2D surface, and you also have to mask out the areas that are not the floor surface because they should not be included in the stitch either. Anyway, this technique works fine for most panoramas, but as I said, it doesn't work on 3D floor surfaces. Perhaps your video's technique would work slightly better for floor surfaces that are not perfectly flat because the viewpoint is not shifted as much, but it a bit scary to tilt the tripod forward at such an angle! Anyway, most of these are problems are solvable with a lot of post-processing, but not easy. :-) Diliff (talk) 14:27, 15 May 2015 (UTC)

Ah, ok, sorry, I thought that you wanted to shot future pictures with a logo :S To be honest, I don't know what is less annoying the logo or the tripod. I wouldn't probably put much effort to get rid of the tripod in already existing images. Thanks for the hint about how to handle the nadir issue with PTGui, I wasn't aware of it. I have tried the video technique and haven't got the problems you mention and I think that our equipment is similar, and probably the more often you do it, the better you can come out. Anyhow, will try what you say. For now you can see the result in the 3 pictures I have linked below, including the shadow issue, which is really a problem (usually masking it out was good enough, but not perfect, of course). Poco² 22:46, 15 May 2015 (UTC) PD: Just notice that the nadir is not shown in 2 of them, no clue why, will look into that.

Btw, as PierreSelim, Raimund Liebert are also attending. Maybe we could also get some support also from Wikimedia France and Austria. Let's lobby! :) Poco² 14:59, 15 May 2015 (UTC)

Hi Poco, I had some potentially good news about the project. I saw that Wikimania 2015 is currently going on, so I decided to bug Daniel Schwen once more about the Panorama viewer. He's agreed to put it on the Hackathon agenda. Not sure what will come from it yet, but fingers crossed. Really, we need a modern professional looking viewer and I'm not sure that can be built in a week at a Hackathon, but anything is better than nothing at this point! Diliff (talk) 15:03, 14 July 2015 (UTC)

Good news. Could you ask User:Dschwen to please please pretty please fix the problem with the zoom viewer. Thanks. -- Colin (talk) 19:34, 14 July 2015 (UTC)

Thanks for the initiative and for letting me know, David, will ask Daniel during Wikimania, he has no escape :) Poco² 21:12, 14 July 2015 (UTC)

No problem. I've been chatting to him a bit about it this evening and it's sounding quite positive. He's planning to use Pannellum as a base which seems to be reasonably good. I don't think it's as full featured or flexible as the best commercial viewers, but it will hopefully do the job for us. Colin, I passed on the request. He was surprised to learn it wasn't already working, he thought he'd fixed it. How long has it been broken? Diliff (talk) 21:29, 14 July 2015 (UTC)

Diliff, I don't really know. Days. It has been fixed many times recently but only seems to stay alive a short while and when I next go to try it out it is broken again. It may be possible to set some health-check monitor on a URL to check for errors, but I don't know anything about the servers hosting it. If it was reliable, I'd recommend it as the default MediaWiki viewer for images above, say, 50MP. The Pannellum option looks good and am looking forward to that experience in Wikipedia. Does it have an annotation feature where we can point out stitching errors or pixel peep about CA? :-) -- Colin (talk) 22:26, 14 July 2015 (UTC)

Colin. Ah ok I didn't realise it had broken itself over and over recently. Here's Daniel's response. ;-) Well, unfortunately as I understand it, the panorama viewer won't be integrated into MediaWiki (at least, not yet), it will only be accessible through the image page, presumably via a template. That's unfortunate because it may be that the only way to link to it directly from Wikipedia may be via a hardcoded external link to the toolserver rather than a Wikified link. I'll wait and see what they're able to come up with but it's probably not the Holy Grail just yet. Diliff (talk) 22:55, 14 July 2015 (UTC)

Daniel showed me yesterday the proof of concept of the new viewer. It looks great!! Poco² 15:02, 17 July 2015 (UTC)

• Yes, he asked me to test it also. It's working very well already, although the version he showed me only displays in a small window, the 'expand to full screen' button doesn't work, and it's currently only very low resolution (my 45mb 18000x9000 resolution panorama reduced to a 500kb low res version). I'm not sure if he will implement multiresolution support yet. So yes it's looking very promising, but we will have to see how much he can do. I wonder what FPC would think of these 360x180 panoramas, given that they need a special viewer to appreciate... And the fact that to appreciate at full resolution requires the understanding that it loads cube faces as it is needed - you don't get the full resolution visible immediately. Maybe we should post something on FPC talk and ask how these files might be handled. Diliff (talk) 15:06, 17 July 2015 (UTC)

Expand to full screen works in the new version and it will be usable from anywhere (users need to add a small template to the image caption). --Dschwen (talk) 15:13, 17 July 2015 (UTC)

Indicating suitable panoramas

@Diliff: , @Poco a poco: , @Colin: , and ping everyone else. We need a way to tag 360 degree panoramas. It looks like no one is using the Template:Pano360 anymore :-(. I cannot rely on categories like Category:Equirectangular projection because they contain many images that are not 360 degree panoramas. The Pano360 template also solves the problem of setting (fov and) horizon line for panos that are 360 around horizontally, but do not provide the full 180 degrees vertically. Next we need to take the discussion to the various wikipedias. I will have to create a gadget that pops up the panoviewer in actual articles (with the help of a little template in the image caption). --Dschwen (talk) 15:14, 18 July 2015 (UTC)

• Well, yes I agree we need a consistent category for these images. One option is to remove any non 360 degree panoramas from the Category:Equirectangular projection and put some text at the top of the category to advise that it is only for full 360x180 degree panoramas. But I'm happy to go with the Template:Pano360 too. I do think it's important to differentiate full 360x180 degree panoramas from 360 degree panoramas that don't have the full 180 degrees vertically. We should have a category that isn't polluted by incomplete spherical views. Perhaps we could create a second template with the name Pano360x180? Just an idea... Diliff (talk) 18:42, 18 July 2015 (UTC)
  • I certainly don't think Category:Equirectangular projection is suitable since that's just a projection, not an indication of FoV or suitableness for the viewer. The Template:Pano360 is used for lots of images, but links to a Java page that my browser won't allow me to run. Is that tool then no longer working (or acceptable in modern browsers due to Java insecurities). If so, it seems a good idea to kill it off as it is misleading and might encourage people to reduce their browser security settings in order to run it. Are all the many hundreds of images linked to that template suitable for your new tool? I think a template coupled with specific category is the best way (i.e., using the template also adds the category). -- Colin (talk) 11:11, 19 July 2015 (UTC)
    • Good point I suppose. I don't think we have to kill off Pano360 necessarily. It could just be updated to refer to Dschwen's panorama viewer instead of the Java one. But I'm still concerned that we should be separating horizontal 360 degree panoramas from 360x180 degree full panoramas, so perhaps two templates could be used that display the image in the same viewer, but apply a different category depending on what kind of panorama it is, instead. That would work for me I think. And would require less admin work than if we had to create a new template and migrate all the images that already have the existing template. Diliff (talk) 12:53, 19 July 2015 (UTC)
      • To me it sounds reasonable to distinguish full spherical panoramas from 360 panoramas both with a different template and a different category. It shouldn't be a big effort to do so. Poco² 16:01, 19 July 2015 (UTC)
• Ok, I will edit {{Pano360}} to change the link (by the way the old java viewer is mine as well :-) ). I suggest we keep it as one single template, but have an hfov parameter that defaults to 180 and if set to anything else changes the category accordingly. --Dschwen (talk) 16:33, 19 July 2015 (UTC)
  • P.S.: I will make a linkable panoviewer page in addition to the gadget that embeds the panorama. --Dschwen (talk) 16:34, 19 July 2015 (UTC)
    • OK, but the problem with keeping a single template is that the template (at least, the way it currently works) applies the category to the image, and we should not categorise a full 360 pano the same as a horizontal 360 pano. If we keep a single template, we will have to separately categorise the images, which isn't the end of the world, but adds an extra step for every upload, instead of a bit of extra work during the planning stage. Diliff (talk) 16:39, 19 July 2015 (UTC)
      • No the template will categorize conditionally into pure 180 and non-180 categories. Doing this is trivial. I just changed the link as a first step, so that it points to a working viewer (some terms and conditions apply ;-). I'm listening to talks right now, so please bear with me. --Dschwen (talk) 16:58, 19 July 2015 (UTC) P.S.: It would be super helpful if you could point me to or create the categories you'd like to have the files sorted into. --Dschwen (talk) 16:59, 19 July 2015 (UTC)
        • OK, I think I see what you're saying now, the category will be determined by the hfov parameter? Or will it be based on if the aspect ratio is 2:1 or not? I'll trust you that the template can do it anyway, but remember that there are a lot of existing non-180 panoramas using the template... So I'm hoping it will use the aspect ratio and not a parameter that would have to be manually added to each one. Anyway, as for the categories... I don't know. In keeping with existing naming for the non-180 panos, we could call it Category:360x180 panoramics. I know that not everyone understands or refers to these panoramas as 360x180 but I think it's a way to be concise and specific. So my vote goes to:
          • 360, non 180 degree vertical FOV = Category:360 panoramics
          • 360, 180 degree vertical FOV = Category:360x180 panoramics
        • I'd be willing to listen to other suggestions though. There is already a sub-category of 360 panoramics called Category:Spherical panoramics which seems to contain mostly 360x180 panoramas (not all), but I don't think 'spherical' is descriptive enough and will probably be misunderstood. No matter what we decide, we will have to do some cleaning up of categories. Diliff (talk) 17:13, 19 July 2015 (UTC)
        • The way our category system works, where everything gets put in dozens of layers of hierarchy, someone will put Category:360x180 panoramics inside Category:360 panoramics, and that would be perfectly logical but probably not what you want if you think the latter excludes the former. We need to separate out images with little-planet projections as they won't render properly but are also 360. I'm a bit confused about the naming. Surely the panorama is 360 vertically and horizontally to enable you to spin around in all directions. Why does Dscwen suggest a hfov parameter -- surely that's always 360? Isn't it the vertical FoV that is sometimes incomplete? Can we have a hierarchical category grouping that is relatively standard, easy to understand, and includes the necessary projection? Alternatively, we could give this panorama viewer tool a sexy name and simply use that as the template name and category name "XXXX-compatible image" and then leave Commons category experts to worry about what category to put that into? -- Colin (talk) 17:34, 19 July 2015 (UTC)

• @Colin: I suggested hfov because my brain is pulp right now. Of course I mean vfov! And the maximum you have there is 180 degrees, otherwise you map the sphere twice (by looking backwards). And yes, we need to specify that the panoramas are in equirectangular projection. Little planet type panos won't do us much good without reprojection. --Dschwen (talk) 19:52, 19 July 2015 (UTC)

Hi everybody! Imho we should avoid categories (which may be gone with Commons:Structured data anyway) and use a template, that can be altered and extended later on. Afaik the new viewer is able to handle equirectangluar and cube-projections right now. But that's not necessarily the end of history. The viewer may be updated to handle other projections (like cylindrical or mercator) and smaller viewing angles in a future version.

Therefore I recommend to use a template as a more sustainable and future proof solution. Imo this template should support the following technical parameters:

• projection: The typ of projection used (defaults to planar)
• angle: The horizontal angle from left to right a (defaults to 360°)
• horizon: The y percentage of the horizon (defaults to 50%)

Additionaly there maybe meta parameters like:

• software The Name of the stitching software used
• imageNo Number of source images used
• hdr true or false

Comments welcome ;) // Martin K. (talk) 19:02, 19 July 2015 (UTC)

• @Martin Kraft: It would be nice if instead of percent values we could work with more clean (projection independent) degree values (see also the panellum parameter docs. The closer we match those the easier the implementation will be...). --Dschwen (talk) 19:55, 19 July 2015 (UTC)
  • @Dschwen: Degree is ok for the horizontal span, but doesn't really work for the vertical position of the hiorizon within the image. An example:
    • Let's say you have a cropped equirectangular 360° pano image sized 2000x800px. Based on the dimensions we know that 36° are missing to the full 180°, but we do not know if it has been cropped at the top, bottom or centered.
    • With the information, that the horizon ist at 50% of the image's height, we know that the crop ist centered. If the horizon is at 55.55%, we know that it has been cropped at the bottom. If the value is at 44.44% it was cropped at the top.

  And this is not limited to projections with a linear degree/pixel-relation. The position of the horizon is also essential for nonliniar projektions like cylindrical oder mercator. And the best thing is, that the horizontal-position is quite ease to find and percent also works in scaled versions. // Martin K. (talk) 21:34, 19 July 2015 (UTC)

  • The horizon position is as easy to find in degrees. For equirect panos there should be a linear relationship between the two. I'll probably run a bot to convert the existing pano360 template parameters and guess the hfov based on the aspect ratio. --Dschwen (talk) 15:37, 20 July 2015 (UTC)
    • You mean vfov I think. ;-) *ducks* Although unless I'm missing something, guessing the vfov isn't useful unless you also know where the horizon is, so a bot isn't going to fix the problem of not knowing the horizon. Many incomplete panoramas show all (or almost) the whole sky but not the whole floor because of the tripod. Ideally the photographer would just leave the tripod and keep it as a 360x180 but they might instead decide to crop the portion that contains the tripod. If this happens, knowing the aspect ratio can tell you the vfov but not how to display it properly. Still, I suppose we can only do our best. Some of them may need to be manually adjusted later. Diliff (talk) 16:40, 20 July 2015 (UTC)
      • Argh, yea, I mean vfov. And yes, the horizon is important, but it always has been and it is a supported parameter in the existing template. As I said, I'll have to run a bot to update the template parameters. The old viewer inferred the vfov from the aspect ratio (assuming 360 degrees horizontally). --Dschwen (talk) 02:15, 21 July 2015 (UTC)

Also: the viewer would support hfov<360 as well, but I guess for those panos we'd need a different template than {{Pano360}} :-) --Dschwen (talk) 19:59, 19 July 2015 (UTC)

• Again @Martin Kraft: we do have Category:Spherical panoramics‎ under Category:360 panoramics. The nesting does make sense to me. --Dschwen (talk) 20:01, 19 July 2015 (UTC)
  • I will change the template so that panos that explicitly specify vfov=180 are sorted into that category. --Dschwen (talk) 20:02, 19 July 2015 (UTC)
    • It would be ideal if it would assume vfov=180 if the aspect ratio is exactly 2:1 and categorise it as a 360x180 panorama? That would simplify things so that you wouldn't need to include any parameters at all for all true 360x180 panos. (well, there is a tiny probability that a non 360x180 panorama would be exactly 2:1 ratio but lets assume for now that it won't happen!) Diliff (talk) 20:56, 19 July 2015 (UTC)
      • Based on an intelligent Template with default values it should be ease to assume thet the pano is 360x180°, if it is 2x1 an no other parameter is set. But since a 2x1 resolution could also mean that the Pano is 180x90° there should also be a possibility to overrule this via parameters. // Martin K. (talk) 21:45, 19 July 2015 (UTC)
        • True, but an exact 2:1 ratio that isn't a complete 360x180 panorama is very unlikely. Possible but unlikely, as it would only be an accident to have a panorama of exactly 180x90° instead of 178x94° or any other arbitrary angles of view. So yes as long as we can override it for exceptions, it should be safe to assume 99% of these are complete panoramas. Diliff (talk) 22:04, 19 July 2015 (UTC)
          • Degree numbers are scale invariant as well. And of course we need a horizon position (we already had that parameter!). In short: if you want this to work soon, we need to use degrees. --Dschwen (talk) 15:34, 20 July 2015 (UTC)
  • Imo the categyories don't really matter as long as we do use a template that we can change later.
    For reasons of sustainability I would suggest to use only one single templates for all types of panoramas and handle everything else via parameters. // Martin K. (talk) 21:45, 19 July 2015 (UTC)
    • OK, I agree with you as long as the complete and incomplete 180 degree vfov panoramas can be determined automatically by the template, then there should be no reason for two different templates. My suggestion for two templates was before Dschwen advised that he would include code to differentiate them. So if I understand correctly, our conclusions are as follows:
      1. We will continue to use the existing Pano360 template, but modify it to suit the new pano viewer
      2. The template intelligently differentiate between full 360x180 panoramas and incomplete vfov panoramas based on the aspect ratio or a manually defined vfov parameter.
      3. The category names are not important just yet, but it is important to have different categories for complete and incomplete panoramas and these categories will be added based on the automatic or manual identification of its type.
      4. Optional parameters for the template could include projection, vfov and hfov along with other metadata not directly needed by the viewer.
    • Is this a fair summary? Diliff (talk) 22:04, 19 July 2015 (UTC)

      Sounds good to me. In the medium term I would suggest to rename {{Pano360}} to a wording, that includes panos small than 360° as well. But that's cosmtics. // Martin K. (talk) 07:41, 20 July 2015 (UTC)

      The only problem with allowing non-360 panoramas is that we will be faced with the problem of having to identify what hfov each one has. If we can assume every one tagged with {{Pano360}} is actually 360 degrees horizontally, then we don't have to do anything. I'd prefer to keep this viewer for 360s personally. I can see how the viewer could be useful for <360° panoramas, but the amount of work needed to make it display properly would be greater, and I think people might start adding the template without the correct parameters and causing the images to be categorised incorrectly (if hfov is not defined, the template would assume hfov=360 and categorise it as a 360 pano). There is the danger that by trying to make the template inclusive to all panoramas that it will cause more problems than it solves. Diliff (talk) 08:31, 20 July 2015 (UTC)

      Imo we wouldn't loose anything when implementing the template so that it is ready for <360 panoramas. Of course the player won't support such panoramas in the first release. But once it does, it would be great if we can just pull the trigger instead of starting another discussion about another template.

      But since I understand your intention to make it as simple as possible, here's another suggestion: Let's create a template named {{Pano}} with all the parameters and options mentioned above and use {{Pano360}} just as an shorcut template for this template with all parameters preseted to display a full 360° equirectangular Panorama?! // Martin K. (talk) 16:35, 20 July 2015 (UTC)

Isn't there a danger, with a very generic name like "Pano" that people will apply the template to any old panoramic photo. I may be misunderstanding, but with the panos that don't sweep through 360-degrees, do you still require an equirectangular projection? I don't see how a viewer that can be angled up/down could reasonably interpret the scene without knowing the projection. For simple wide-format panoramas (whether rectilinear or cylindrical), isn't the zoom viewer sufficient? -- Colin (talk) 06:56, 21 July 2015 (UTC)

• The name {{Pano}} was just a suggestion. If that's not accurate or missleading, we can use another name instead. Any suggestions?
• As written above, this template will require some paramters, to define how the panorama is viewed within the Pano-Viewer. And if we use {{Pano360}} as an shortcut for paramters of an full 360°x180° equirectangular pano, we could also get along with out any presets. So that using {{Pano}} without any parameters does not activate the pano-view at all. Therefore it is ok, if people use it for any type of panorama.
• Imho zoom viewer isn't a good solution for any equirectanglar oder cylindrical projection, because it displays all the straight edges bended, which isn't very naturalistic and the main reason for not using such images in articles. For every viewing-angles beyond 120° a panoviewer is by far the better displaying technic. // Martin K. (talk) 13:19, 21 July 2015 (UTC)

I just discover this discussion. May I contribute my 2 cents?

• Using hugin, I created equirectangular, cylindrical and rectilinear panoramics in the past.
• Metadata from hugin already contains hfov and vfov info, but these numbers are incorrect if the image has been cropped within.
• Are parameters (percent, degrees) required to be integer?
• Category:360 panoramics automatically adds the Pano360 template, but does not allow to pass parameters.
• Automatic categorisation when using the template may be unwanted once Category:360x180 panoramics in Nether Poppleton comes into existence.
• Usage info on the template page should include more than one example.

So far my thoughts. -- KlausFoehl (talk) 15:17, 3 September 2015 (UTC)

RAW files for panoramics

Its open commonsarchive in wmflabs for upload all RAWS files in a 7zip file, In this way it could be left open the future possibility of improving the bonding of the RAWs --The Photographer (talk) 14:52, 15 May 2015 (UTC)

More spherical panos

Hello, I have uploaded my first spherical panos, two of them are the result of 176 frames (so high due to 5-frames-HDR) and one of 105 frames (3-frames-HDR):

• File:Panorámica esférica de San Pedro Los Francos, Calatayud, España, 2014-12-29, DD 01-176 HDR PAN.jpg
• File:Panorámica esférica de San Andrés, Calatayud, España, 2014-12-29, DD 01-176 HDR PAN.JPG
• File:Panorámica esférica del Seminario de Nobles, Calatayud, España, 2014-12-29, DD 01-105 HDR PAN.JPG

I have also created a test template (Template:Sphericalpano) that I I included in all description pages with a link to http://sky.easypano.com/ , the best site I have found for uploading and viewing panos outside Wikipedia (nice big window, good performance, no publicity, ...). Furthermore I have included the external link in some templates like here (see image caption in the template). Poco² 22:34, 15 May 2015 (UTC)

Wow Poco, nice work, please, dont forget upload it zipped to commonsarchive (If you want do it, of course). I want try the same with photoshop --The Photographer (talk) 23:09, 15 May 2015 (UTC)

Agreed, nice work, although I have to say... The tone mapping / exposure blending in File:Panorámica esférica de San Pedro Los Francos, Calatayud, España, 2014-12-29, DD 01-176 HDR PAN.jpg doesn't look good. The stained glass is very weird looking and the overall brightness of it is too high. I guess it was probably a bright interior already, but it needs more contrast. Are you still using Enfuse/Tufuse to blend exposures? I would really recommend switching to a better method if so. I think your HDR images are being let down a bit by the blending. Oh, and also, it has some stitching faults in a number of places (eg on the right side of the organ) so I guess you needed to adjust the pano head settings a bit, and the columns and leaning slightly. The others seem to have better HDR processing, but still have the same stitching problems. As for some missing the zenith and nador, the versions on Commons are not missing them, so I guess it must be a fault with the sky.easypano.com viewer. Also, the sky.easypano.com does indeed have no ads and more space on the page for the panorama, but I really don't like the method for moving around the scene so much: the way you have to click and then move the mouse to make it follow the pointer and the further from the click point you move, the faster it rotates. I think you have much much more control and a better sense of movement with 360Cities' method where you simply drag the panorama and it the movement follows the mouse directly, you know what I mean? Is it possible to change the default control mode in easypano.com? 360Cities allows both movement options and has a lot more projection options too, but I agree it's not very suitable to link to from here. I believe it uses the KRPano code though. I just hope we can implement a really good pano viewer here, and hopefully we'll have a lot of input into how to make it work best. Diliff (talk) 10:00, 16 May 2015 (UTC)

Viewer

we need an viewer to put these Panoramas into the articles. At the Moment a good camera, the Ricoh Theta S is available, which will do this in one shoot. --Jörgens.Mi ^Talk 15:32, 4 April 2016 (UTC)