Join lines on sky with horizontal stripe

[AaronSpence]

G'day Guys,

I'm getting join lines in the sky of the images where the top & bottom cube faces meet. At first I thought it was caused by the jpeg compression bleeding between the sky & the ground tiles in the horizontal stripe, but since I changed my cube dimensions to a factor of 16, that is definitely not the problem. (7680x1280px)

http://www.pano.com.au/vr/00002145-L.swf

Goto the nearest pylon of the Sydney Harbour Bridge & look up about 20 degrees, there you'll see the line running horizontally across the sky, and the same on the opposite side of the same zenith cube face.

http://www.pano.com.au/vr/00002145-L.jpg - the still image.

Any ideas much appreciated.

Thanks, Aaron.
www.pano.com.au

[joantna]

Hi Aaron,
I have suffered the same problem. In my case it hapens if I retouch the image after converting from spherical projection to 4 cube faces. By 'retouching' I mean increasing sharpness or compresssing to Jpeg. As I work the photo in BMP format and spherical projection, the final step is to convert to cubes and compress to Jpeg. What I have observed is that the maximum jpeg compression that I can apply depends on the size of the image, for compression ratios below 60% sometimes I find the join lines.

Hope it helps

Regards

Josй Antonio

[phberlin]

Hhm, this kind of problem never occurred to me. What software do you use for your workflow?

Here's my suggestion (I'm working on Windows):

1. Taking the fisheye photos in RAW format, fixed exposure, fixed white balance
2. Converting the RAWs to TIFF (I use the free converter "RAWTherapee (http://www.rawtherapee.com/)", but whatever suits your system and personal needs would be OK)
3. Loading the TIFFs into Hugin (http://hugin.sourceforge.net/) (free panorama creation software), finding matching points and so on
4. Let Hugin create the pano as multiple TIFFs
5. Use EnblendGUI (http://digitalretrograde.com/Projects/EnblendGUI/) together with Enblend 3 (http://enblend.sourceforge.net/) to blend the multiple TIFFs seamlessly.
6. Load all the multiple TIFFs into Photoshop or GIMP as layers of a single image. Also open the already blended pano (Enblend output) and put it as lowest layer into the new image that already consists of the multiple TIFFs.
7. Make all alpha channels of the multiple TIFFs entirely black (so you only see the already blended pano). Then retouch unwanted objects by painting with white on the respective alpha channel of one of the Multiple TIFFs.
8. Flatten image when satisfied.
9. patch nadir if you want to using SuperRune (http://www.superrune.com/technical/software_spheretocubic.php)
10. Sharpen image, adjust colors and so on. Save file as TIFF without (!) alpha channels.
11. Convert that TIFF file to cubes using the free DOSUP (http://www.pinlady.net/vr/#anchor3).
12. Convert these cubes faces (they're now still 16bit TIFFs) to JPEGs with a compression of your choice.

And you're done. This way you should encounter no problems like unwanted lines or what so ever. Plus you always have you originals in 16 bit/channel color depth if you want to change anything later.

Hope that helps,
regards, Ph.

[AaronSpence]

G'day Guys,

I appreciate the detailed responses very much :) I've done a new test in SPi-V (a hardware accelerated shockwave viewer) which uses the same jpg strip as FPP. Using the exact same .jpg file in this viewer I'm getting the same line at the zenith border.

http://pano.com.au/vr/spiv/test.htm - SPi-V viewer

So that means it has nothing to do with FPP, and everything to do with my file. It was created with an early private beta of Pano2Vr, so I'll let the developer know.

I'll report back what I find out, and thanks again.

Aaron.
www.pano.com.au

[testure]

I have the exact same problem, very strange.
http://virtualsweden.se/fullscreen/1.htm

I do Equirectangular image first, then I export to QTVR and then extract to stripe with immervision.

Would be very glad if this could be fixed.

[Denis]

There are two problems:

1. Image resampling. When you change image dimensions, contrast borders are blurring. In this example blue pixels take some yellow, yellow pixels take some blue. It can be visible only for far spaced faces (left face - up face, up face - down face). Two blue lines are not so visible on variegated background, but you can find them as well on your panorama (at the down and at left).
How to avoid it: do not scale your image after stripe creation. If you need to change stripe's dimensions - cut faces from the stripe, scale them as a separate images, them put them to the new stripe.

You can repair this images replacing blurred pixels with neighbourhoods: i.e. copy pixels column 5121 and paste it to column 5120. It cover the fist gap in the sky. :) And so on...

2. Jpeg compression. Yes, there is a color's bleeding if face's borders are inside jpeg blocks (8x8). You can avoid it if your face width are divisible by 8. I.e. your stripe width should be divisible by 48. It's OK now (7680/48=160), but your stripe suffered from scaling. :)

So, the ultimate solution is to create your stripes in final width by factor 48 at once.

[AaronSpence]

Denis,

Thanks for the detailed post and final answer to the question. Much appreciated. You have solved this problem on 2 levels though. 1 providing a direct answer to the problem & 2 providing FPP 2.2 with the ability to play QTVR.mov's :)

I was going to start outputting all my work to horizontal stripes for FPP today, but now they'll be QTVR.mov's instead with subtiles for preloading...Loving your work :)

Thanks again,

Aaron.

[testure]

I have the problem even if I am not resizeing the images. I use pano2qtvr to make cubics. And I find the new mov plugin to be far to slow to use. So here is my 2 problems.

1. Equirectangular makes distortion in zenith and nadir
2. CubicStripe makes lines in the sky.
3. Mov is to slow to use.

The only thing I am left to is using separate cube faces and with projects running up to 100 panoramas that is not an option with 600 files to keep track on.

[Dalileis]

God, kinda miss Sverige, looking at your Malmц pano there, Jonas.

Try this:

1. Update pano2qtvr to last version

2. Take controll over tile settings within pano2qtvr. This way pano2qtvr warns you when the tile setting will produce seams:

"The tile size is not optimal for your subdivision selection and will produce seams! Should I correct the tile setting to xxxx?" (pano2qtvr warning)

The xxxx at the end is usually a number which differs by 1 pixel up or down from the originally chosen value.

I've never encountered any visible seams problems doing it this way.

As for the movs being too slow to use, my experience is quite different, performance goes up instead, especially if using higher segments values.