Correct vertical stitch line in Pano2vr?

[Hudson Creative]

Images are imported into Lightroom.
Basic preset applied, color adjustment, sharpening, levels etc. Nothing too fancy.
Images are exported out full size (set to export at 7000px with Don't enlarge checked) with a "watermark" image applied which is actually just the nadir patch logo at the bottom.

It's odd. I can literally export the same image multiple times without changing anything, and sometimes I get the hairline, and sometimes I don't. This is where the extra pixel of overlap makes it simple. There are definitely other z1 users that have had the same exact thing happen. I was just hoping there was an easy way to incorporate the same "fix" that Kuula has built into their platform. Obviously I much prefer P2vr as I have already outgrown Kuula.

[Hopki]

Hi,
"Other Z1 users have this".
I can honestly say this is the first and only report I have seen to do with a Z1 camera.
It is known this happens when the image has been resized but never seen this when the image has not been resized.
Are you saying you resize to 7k in Lightroom?
Can you send one of your DNG files that has this issue to me?
Regards,

[Hudson Creative]

A simple search on the z1 FB users group will find lots of users who have had as they refer to it "the dreaded stitch line".... one theory is using dehaze increases the chances of getting it. I do not re-size my images... that's the preset of 7000x7000 with Don't Enlarge checked... which means any file smaller than that which the z1 file is, it will export at the original size. I'll have to dig deeper to see if dehaze is really the culprit. It was just easy in Kuula to get rid of the line.

[k.ary.n]

So, to recap. In order to publish a tour on Zillow, you need to use their 3D Home app and the file settings are automatically chosen for you, right? That leaves you with only the JPEGs to edit or can it be set to do JPEG+RAW? It's general best practice to not edit the JPEG, but rather edit the RAW and export it as JPEG.

Have you tried bringing in the unedited version of the image in to Pano2VR and seeing if you still get the stitch line?

[soulbrother]

... one theory is using dehaze increases the chances of getting it.

It seems to be clear to me, but of course I might be wrong...
LR is not designed to modify 360 panos.
So, it can be that some differences between left and right end occurs and if this is the reason ( and I am quite shure that it is), it´s NOT on Pano2VR or any other programm to correct the ERROR that has been done before.

Simply choose a workflow that does not cause errors...

And it is easy to determine whether LR produces this error, such tests take a few minutes only ...

[Hopki]

Hi,
To check my understanding you do all your adjustments to the DNG file then on export from LR it opens the Ricoh stitcher and creates the equirectangular TIFF, and you still see the line?
Regards,

[Branigan]

Hi,
To check my understanding you do all your adjustments to the DNG file then on export from LR it opens the Ricoh stitcher and creates the equirectangular TIFF, and you still see the line?
Regards,

Unrelated to this specifically, but Pano2VR does not like changes in tile size that don't divide nicely into the original panorama width and stitching goes weird.

Also, as you've got a Z1, try this: Set Multi-Res, Tile Size to Manual, Set Width to 2000 and render. Interesting result...

What is going on there and what is that option intended to be used for?

Just for fun: it's not consistent, so can't tell if it's the viewer picking things up incorrectly, or the tiles being created wrongly.

[360Texas]

Branigan wrote

Unrelated to this specifically, but Pano2VR does not like changes in tile size that don't divide nicely into the original panorama width and stitching goes weird.

This is true... but mathematically interesting and while the imaging dimensions are different than yours.... our stitched image* width is 6000 x 3000 pixels.

Often we use 6000 x 3000 16bit .tif file type. 16bit image increases detail and color. Our Level values are evenly divisible by the Level tile size.
Advantages: Reduces the number of tiles. When looking in the Tiles folder we found about a 30% reduction in number of tiles. There are no partially filled tiles. Fewer tiles still gets the job done and the project Mb is smaller. Smaller project means faster upload to server.

*edit

Some software uses divide by /3.1415 other software uses / divide by 4 which might leave at 1 pixel overlap issue. We do not know what value your software uses. BUT Pano2vr gives you the opportunity to decide.

Notice that the Level 2048 size when divided by the Level tile size 512 results in a whole number like 4

Level tile size is 512px
Level 1 2048 where even multiple 2048 / 512 = even value even 4 a whole number.
Level 2 1024 where even multiple 1024 / 512 = even value 2
Level 3 512 where even multiple 512 / 512 = even value 1

When you do not use the proper Level tile size and proper LEVEL value... odd issues like overlap occur.

[Hopki]

Hi Branigan,

but Pano2VR does not like changes in tile size that don't divide nicely into the original panorama width and stitching goes weird

This should not be a problem, can you show me an example of what you are seeing?

Also, as you've got a Z1, try this: Set Multi-Res, Tile Size to Manual, Set Width to 2000 and render. Interesting result...

Hahaha, you would not set a tile size to 2000px but that said it still looks ok to me!
What do you see? I also don't get what you're saying about odd size equirectangular images?
My Theta test image for this post out of the Ricoh stitcher is 7296 x 3648px
If the level tile sizes can not be square then Pano2VR will make different size tiles to compensate.

Under settings/preferences and the advanced tab, you can also set divide by PI.
This will give you a slightly sharper image as the default is divide by four.
Of course, you will then start to see some odd-sized tiles, but again not a problem.

I have been using Thetas for years and never seen an issue.
I have however seen a few posts where people have issues in Lightroom and playing with things like auto aline in HDR etc.
But not seen anything other than this.
Very odd,
Maybe send in a project that has these issues, select Support Package from the Help menu and include your panoramas and skin.
Regards,

[Branigan]

Hi Branigan,

but Pano2VR does not like changes in tile size that don't divide nicely into the original panorama width and stitching goes weird

This should not be a problem, can you show me an example of what you are seeing?

Also, as you've got a Z1, try this: Set Multi-Res, Tile Size to Manual, Set Width to 2000 and render. Interesting result...

Hahaha, you would not set a tile size to 2000px but that said it still looks ok to me!

I'll go back and recreate some stitching errors and post some images. Once you know where to look you should be easily able to reproduce it on anything else. Helps if the images have some structure where it's obvious. Not going to see it on a landscape.

As for setting the width to 2000, I was just exploring the options (why else are they there?) and trying higher tile sizes to see if it would help counter the blurring (now we're part way there with the Lancsoz3 filter), but the result I got on several occasions was: completely random tile selection, so parts of a lower resolution front view would be plastered over areas in the background at smaller resolutions. It was like someone had grabbed different sizes of random tiles from the various resolution tile folders and pasted them over the inside of the "box", so there were weird steps in and out and repeated sections. It all looked quite Escheresque.

It did not do it every time, so changing the sizes up and down seems to trigger it having to recreate everything and sometimes it would be bad and sometimes not.

Possibly a caching issue? Wouldn't be the first one.

Only had this in Multi-Res obviously, so went back to Single-Res.