Problem when specifying resolution

[Per Hansen]

Hi,

I run into this problem, when combining a kvrCropStere followed by a kvrViewer node while processing VR180 from a Canon R7 with its dual fisheye lens.

The output of the Crop node is : 6344x3172

the viewer node is set to fisheye manual resolution of 3840x3840 and when previewing the node all looks fine and it gives the stereoscopic 7680x3840 I expected. But on all the following nodes the image looks wrong:

It has correct dimensions - but it looks like it has cropped just a small portion in the lower left corner.

Am I doing something wrong ?

If I use the automatic resolution everything looks correct - but the resolution is 6344x3172, which is less than desired.

Also I am unsure about if I risk loosing resolution in general - what is the optimal way to get the most out of the raw material pixels ? I try to avoid scaling anything down and then up again.

Also a small suggestion - could height and with be optionally synced in the crop node - with VR180 its convention to have those the same so it would make it easier to get the right aspect.

Sincerely Per

[Andrew Hazelden]

Hi Per.

It's early here (4:39AM) so I will keep this reply ~fairly short.

> It has correct dimensions - but it looks like it has cropped just a small portion in the lower left corner. Am I doing something wrong ?

There is a note on the Kartaverse Fuses documentation page that provides a tip to use the Autodomain node to solve this type of framebuffer sizing issue.

So... you will need to add a Fusion native "Autodomain" node right after your final chain of interconnected KartaVP DCTL fuse nodes. This helps to solve a DCTL fuse image framebuffer resizing issue related to DoD (Domain of Definition) resizing calculations of the Fusion ROIDS region of interest. The DoD values and other image parameters are passed between nodes, which means placing an Autodomain node after a series of KartaVP fuse nodes change the canvas size is a good step.

FWIW, a longer term solution, that would not require this Autodomain node usage, is under development now but it requires the use of undocumented/under-documented Fusion DCTL Fuse API features.. so the dev progress is generally slower on completing this change than I would otherwise like to see.

* * *

If you look in the Reactor Package Manager at a new "Kartaverse Lens Profiles" atom package you will see the start of a kvrFisheyeStereo macro node. It's so new that I'm still writing the docs for it and making example tutorials and project files, etc. this week. :)

Look at this "Kartaverse Lens Profiles"  example comp if you want to see an example workflow demo:

Reactor:/Deploy/Comps/Kartaverse/KartaVP/Lens Profiles/RED/V-Raptor/STMap_RED_Digital_V-Raptor_RF5.2mm_DF_SRC_7680x4320_DST_8192x4096_Hugh_Hou_LivingRoom_v001.comp

The kvrFisheyeStereo node is the prototype for a unified workflow that allows you to cycle through a "View Mode" control to preview each of the primary image processing stages for 180VR dual fisheye SBS post-production. Once the kvrFisheyeStereo macro's features have been refined over the next few weeks/months, and tested with user feedback, that tool will be turned into a single-purpose unified DCTL fuse for optimized dual fisheye 180VR SBS media processing. I anticipate that a unified approach to do all of the rendering tasks inside a single DCTL fuse should boost rendering performance by 2x - 4x, with lower VRAM usage. Time will tell how much the IRL performance change turns out to be when this is applied to media post-production tasks in real-world workloads.

An upside for the final unified DCTL Fuse version of the kvrFisheyeStereo node, is that it should be able to more dynamically handle the automatic image resolution aspects of the interconnected steps. This will streamline the STMap creation process when dealing with the cropping of dual fisheye imagery down to the active circular fisheye image data, then proceeding onwards to deal with the other image projection conversion steps.

* * *

The Kartaverse PT (Panotools) data node project has a ptBatchStitcher node that can render out a PTGui Pro .pts project files and the PT data nodes can return the resulting media to a Fusion node-graph on the fly. This is part of another path to create STMap templates for 360VR/180VR workflows if you are comfortable with STMap approaches.

In time, a few more Panotools data node fuses will be added that help streamline a one-step conversion of a stock .pts JSON file into a set of multi-view STMap templates. This would modernize the earlier KartaVR 2017 era's "Generate UV Pass Templates" scripted workflow that ran using PTGui Pro v10 based (ptstitcher syntax) .pts file.

Regards,

Andrew

On Saturday 10 August 2024 at 03:59:42 UTC-3 per.kofo...@gmail.com wrote:

Hi,

I run into this problem, when combining a kvrCropStere followed by a kvrViewer node while processing VR180 from a Canon R7 with its dual fisheye lens.

The output of the Crop node is : 6344x3172

the viewer node is set to fisheye manual resolution of 3840x3840 and when previewing the node all looks fine and it gives the stereoscopic 7680x3840 I expected. But on all the following nodes the image looks wrong:

[Per Hansen]

Hi,

Thanks a million for the swift early response. - I did try it out immediately, even though only replying now. And it worked ! :)

I will take a look at the lens profiles also and see if I can grasp it. I dont have a lot of experience with STMaps, but I can see they provide some possibilities in general I'd like to learn.

Thanks again for the great work.

Now I need to figure out how I can use the spherical stabilizer (which is meant for stabilizing 360 video) to stabilize dual 180 degree lenses.

/Per