Zooming out in Studio - Perspective Distortion

wiz

barbult said:

Could it be that DAZ is fully aware of the problem and how to fix it, but have chosen not to, because it would be incompatible with all existing saved scenes?

No, that's not the reason, at all.

Programs have similar bugs fixed all the time. A proper fix checks the version of a saved file, so you get the expected behavior on older files.

Arcane Von Oblivion

you know this is very interesting what I read here so far. One thing to remember here is this. Lets say that all of the sudden Daz thought that the issue required a so called fix. They couldn't do just a Fix that would change what was already going on in the program. If they would change the default way that the cameras are working now for the few people that noticed it, It would affect the other 90 percent of people that didn't and get them pretty mad really quick.....lol. So while I agree that it is a problem that (not only Daz, Poser also) cameras are not 100% accurate to the real world. Changing this would have to be an added feature (not default) rather then a Fix. So I can understand what Jared means.

It's not so different from selling tires or anything else for that matter. Standards take a really long time to make. (you'd have a monopoly if every software "corrected" flaws that work). I know its kind of off the issue of the thread, but My solution would be rendering in the program that's closest to what you need until there is a standard. Daz sells Meshes, Studio is just a plus to them (I believe). You can use those meshes in ........ any other software.

I'm sorry if I am out of place with this. I'm just trying to give a different view on the subject in general from an outsider that noticed that the Poser and Daz studio cameras are different. I Agree that there is no standard....

Rayman29

Just to to be clear, camera focal length and another arbitrary FOV parameter do not mix. Result, just a hybrid of wrongness XD.

Blender might be a better option though.

linvanchene

you know this is very interesting what I read here so far. One thing to remember here is this. Lets say that all of the sudden Daz thought that the issue required a so called fix. They couldn't do just a Fix that would change what was already going on in the program. If they would change the default way that the cameras are working now for the few people that noticed it, It would affect the other 90 percent of people that didn't and get them pretty mad really quick.....lol.

I know I wrote a lot in this thread so it is easy to skip some points.

But actually Richard provided an awesome suggestion with the presets.
At least for the way how the viewport is cropped a solution could be to simply add a different way how the viewport is cropped.
If another preset is added all users who do not want that can keep using the default preset as before...

It may come as a big surprise to DAZ Studio users but in other render engines you often find many different camera presets.

Example:
Thin lens camera
Panoramic camera

There is no need for DAZ Studio 3Delight users to get mad. They can keep using the current preset as before.
- - -

If you want to avoid the distortion then the easiest way is to render everything 1:1 and crop when its done.

The current situation is very time consuming for all those people who wanted to create web banners or any other images that have a lenght to height relationship larger than 2x1 like 5x1, 10x1.

It really seems like a waste of time and money that we have to render images at 1920x1920 if we just wanted to create a banner of the size 1920x360.

And as mentioned this is even more inconveniant for those who are working for print.

You do really not want to render an image at

3840 × 3840 if you just need 3840x640.
and of course it is even worse at
7680 × 7680 if you just need 7680x1280.

Time is really of the essence if you are rendering at those large resolutions. You do not want to render one pixel more than you actually need.

But in any case adding an alternative way to crop the viewport would provide a solution that does not take anything away from any other user.

- - -

Standards take a really long time to make.

There is a standard for camera film and sensor size. It is called 35mm film.
It was introduced by Kodak in 1934.

http://en.wikipedia.org/wiki/135_film

And so far the same standard was adopted for analogue and digital photo cameras.

For most 3D software it has become custom to base the camera system on a default 35mm sensor and use a 3x2 aspect ratio as default sensor aspect ratio. All croping of the viewport happens based on that sensor size and aspect ratio.

And as allready was established that cropping happens inside the default sensor size.

Some 3D software also provide the option to select an alternative sensor size or film size.
If any camera would use a different film size or later on sensor size a crop factor is provided to calculate the changed values.
The crop factor is also called focal lenght multiplier.

http://en.wikipedia.org/wiki/Crop_factor

There are formulas out there that you can use to calculate any values related to cameras.
There are even very useful sites in the internet where you can enter those values:

Angular Field of View Calculator

http://www.tawbaware.com/maxlyons/calc.htm#fov_calculator

You can use the Angular Field of View Calculator to find out the field of view you get by a specific focal lenght in comination with a specific focal lenght multiplier.

Example 1:
You know that your professional photo camera has a full frame 35mm sensor.
This means the crop factor / focal length multiplier is 1.
You know the widht and height of the image sensor has a ratio of 3x2.
The focal lenght of the lens is 50mm.
If you enter those values in the Angular Field of View Calculator you get
a horizontal Field of View of 39.6 degrees.

- - -

Example 2:
You know that your small camera you use for holiday trips has an APS-C sensor.
This means the crop factor / focal length multiplier is 1.5.
You know the widht and height of the image sensor has a ratio of 3x2.
The focal lenght of the lens is 50mm.
If you enter those values in the Angular Field of View Calculater you get
a horizontal Field of View of 27 degrees.

- - -

Similar to those examples there must be some kind of calculation we can apply to figure out the corrected focal lenght value we need to
enter in the DAZ Studio camera tab to get the field of view we actually want to see in the DAZ Studio viewport.
Is there really noone in the DAZ Studio team that can provide that formula?

- - -

In any case it should not be such a huge issue to provide additional camera presets.

If you have a look at other software they allready did that and it is possible to achive very precise results.

Example:
Maya supports RenderMan, 3Delight, V-Ray, Maxwell Render, Octane Render etc.

Each of them may have a slight different way how camera values and the viewport are calculated.
But it is possible to support each of those render engines in one software without negative consequences for all other users.

- - -

Currently I am waiting on the release of the OctaneRender plugin v2.x.
That version will add the option to export a scene from the plugin to the standalone and later the cloudrender version.
If everything works as expected a scene rendered in the DAZ Studio plugin should look exactly like a scene in the standalone and cloudrender version.
In that case the plugin developer was able to find a way to override the DAZ camera system and the viewport.

But I suspect that this will not work. I suspect that the code for alternative ways to crop the viewport must be provided by DAZ and included in the DAZ studio SDK.

But as mentioned currently I will wait and see what happens.
I write this so it is clear that for me this issue is not solved but just on hold until the gravity of the situation can be judged properly.
This also means that independent of any plugin based solution alternative preset options must be provided for DAZ Studio 3Delight users, Luxrender users and later on RenderMan users.

Hole

http://www.fundza.com/rman_booklet/advanced_camera.pdf

Field of View

In real world photography it is convenient to change the field of view either
by selecting a lens with a different focal length, or as in the case of a zoom
lens, by directly altering its focal length. When setting up a virtual camera
with RenderMan it is more convenient to accept the default focal length (1.0
unit) and directly adjust the fov parameter using the Projection statement, for
example,
Projection "perspective" "fov" 40
Unfortunately fov is measured slightly differently by RenderMan compared to
normal photography. In photography fov is measured across the diagonal of
the film plane, while in RenderMan it is measured across the narrower of the
two sides of the image. It is particularly important to take this difference into
account when trying to match the view of a virtual camera to that of a real
camera, for example, when compositing images from photography and
computer graphics.

linvanchene

- -

Feature Suggestion:
Add the horizontal and vertical Field of View parameter to the DAZ Studio Camera tab

Hole said:

http://www.fundza.com/rman_booklet/advanced_camera.pdf

Field of View

In real world photography it is convenient to change the field of view either
by selecting a lens with a different focal length, or as in the case of a zoom
lens, by directly altering its focal length. When setting up a virtual camera
with RenderMan it is more convenient to accept the default focal length (1.0
unit) and directly adjust the fov parameter using the Projection statement, for
example,
Projection "perspective" "fov" 40
Unfortunately fov is measured slightly differently by RenderMan compared to
normal photography. In photography fov is measured across the diagonal of
the film plane, while in RenderMan it is measured across the narrower of the
two sides of the image. It is particularly important to take this difference into
account when trying to match the view of a virtual camera to that of a real
camera, for example, when compositing images from photography and
computer graphics.

Thank you so much. This is exactly the formulas and information I was looking for to better understand what is going on.

The question now is:

Does 3Delight in DAZ Studio also work that same way?

If that would be the case there might be a more or less simple solution to at least be able to composite an image created in DAZ Studio to an image created in any other software or a real world camera:

- Add the horizontal and vertical Field of View variable to the camera parameters.

Then all we would need to be able to do is to

- change the horizontal or vertical Field of View parameter independent of the Focal Lenght.

It may be as simple as clicking on the Field of View and the Focal Lenght parameter in the camera tab and removing the link.

Then what we can do is:

Set Focal Lenght at 1 as suggested.
Adjust the Horizontal or Vertical Field of View parameter to the value we need.

- - -

It would be a first step and a partial solution for those 3Delight users who are trying to match their images with real world photography or other 3D software.

It still would make sense to add other camera presets to DAZ Studio that are based on the needs of other render engines.

linvanchene

I make a new post for this to separate the idea posted in my previous post from this one.

Feature Suggestion:
Add Camera presets for each render engine to the viewport and the camera tab

Richard Haseltine said:

As I understand it the reply is saying there are two ways DS could handle aspect ratio - it could assume a frame equal to a real camera's and crop within that to give the desired proportions, or it could allow the frame to grow to accommodate the desired proportions - essentially it can treat the the virtual 35mm (or whatever) frame as a maximum or minimum. DS is being said to do the latter, the wish here is for it to do the former - I see nothing in the quoted response to indicate that a feature request to make it a user-preference which DS did would be rejected out of hand, merely a statement that having chosen the option of the two available that the ticket posters didn't want is not a bug per se.

Edit: sorry, the forum took me to the last post isntead of the first new post and i missed that Slimer_J_Spud had already said much the same.

This post by Richard inspired me to think more about the way plugins are integrated into DAZ Studio.

The way I interpret this suggestion would be to add the following features to DAZ Studio.

DAZ Studio Viewport:

In the viewport pull down menu in addition to the "default" camera additional presets for each render engine plugin are added.

The idea is that each render engine plugin may benefit from different ways how the OpenGL viewport is displayed.
Guide lines like the focal planes that are not used by some plugins are hidden away in the plugin camera presets.
Additional guide lines that are used by the specific plugin are added to the viewport.
The viewport is cropped based on the parameters that most benefit how the specific render engine plugin operates.
Some render engines may provide the user with several different camera presets.

Examples:
- For 3Delight an additional preset is added that "cheats" around the current viewport cropping and gives the user the option to render images with extreme aspect ratios like web banners without distortions.
- For OctaneRender support for the Thin Lens and the Panoramic Camera presets can be provided.
Currently this is not yet the case. The Panoramic Camera is only supported in the standalone version of OctaneRender.

DAZ Studio Camera Tab

In the DAZ Studio camera tab each render engine gets its own subtab.
This lets the user quickly change between different camera values used by the different plugins.
The camera values displayed depend on the render engine plugin the user has installed.

Example:
Users who have not installed the OctaneRender plugin do not see those values.
This is allready the case now.

Currently 3Delight does not yet have its own submenu. Because of that default 3Delight and OctaneRender camera values are mixed together when the top level menu "Camera" is selected.
Therefore currently it is not possible to select only those camera values that are controlled by 3Delight when a plugin like OctaneRender is selected.
- - -

If the user opens the pulldown menu of the DAZ Studio camera tab and selects "add camera" he can choose from the same camera presets as in the viewport camera pulldownn selection.

The "add camera" menu is not shown in the screenshot. It is accessed from the pulldown menu that opens when clicking on "Default Camera".

- - -
- - -

As mentioned I will now not immediately submit a feature request.
I will wait until the OctaneRender plugin v2.x is released to see how the DAZ camera system affects the plugin.

Nevertheless if you are using 3Delight, LuxRender or want DAZ Studio to be ready when a RenderMan plugin arrives feel free to create your own feature requests now.

The screenshot attached was manipulated in photoshop to illustrate the ideas.

Hole

Does 3Delight in DAZ Studio also work that same way?

Yes.

It still would make sense to add other camera presets to DAZ Studio that are based on the needs of other render engines.

Those other render engines are pure raytracers, they're better optimized to handle the amount of raytracing needed to simulate different lenses. It can be done with 3Delight/Renderman with camera shaders but you take a big performance hit. You're basically pulling into the DAZ gas station and telling them you want high octane gasoline in a diesel powered car, it can be done but you probably won't like the results.

The pros don't bother with doing lens simulation in 3DL/Renderman, it's easier for them to use their compositing software to remove lens distortion from the backing plate or to add it to the rendered frame, which involves working at a higher resolution and cropping like Richard suggested.

If you're really interested in having special cameras inside Studio, you can find examples like this:

http://www.renderman.org/RMR/Shaders/fisheye/index.html

and use this tutorial:

http://www.sharecg.com/v/66014/browse/3/PDF-Tutorial/DAZ-4.5-Shader-Builder-Tutorial-MK-Gooch-Shader

to get them into Studio.

With the recent improvements to 3DL's raytracer it might be more feasible than in the past, but it's still a lot of work for something that can be done in Photoshop and even more work to make it consistent with other renderers.

...it might be possible to deal with the Renderman FOV thing with a script that spot renders inside the FOV circle like a real camera instead of outside of it.

linvanchene

- - -

Summary:
The three different issues discussed in this thread and their possible solutions

Hole said:

Does 3Delight in DAZ Studio also work that same way?

Yes.

It still would make sense to add other camera presets to DAZ Studio that are based on the needs of other render engines.

Those other render engines are pure raytracers, they're better optimized to handle the amount of raytracing needed to simulate different lenses. It can be done with 3Delight/Renderman with camera shaders but you take a big performance hit. You're basically pulling into the DAZ gas station and telling them you want high octane gasoline in a diesel powered car, it can be done but you probably won't like the results.

The pros don't bother with doing lens simulation in 3DL/Renderman, it's easier for them to use their compositing software to remove lens distortion from the backing plate or to add it to the rendered frame, which involves working at a higher resolution and cropping like Richard suggested.
.

Thank you so much for adding the additional information how 3Delight / Renderman works.

I guess I did not a very good job of separating the three different issues.
I try to give a summary of everything proposed so far in this thread.

- - -

1) Distortions of the DAZ Studio viewport when working with 3Delight
solution: add another crop preset to cheat to create webbanners with 3Delight

My main argument here is that it is not time and money efficient to render the whole image and then crop in postproduction.
We really should only render exactly those pixels we need when working with higher resolutions.

If you want you can also consider this as a request for an advanced version of a region render that lets you choose which area of the default viewport is actually rendered.

You can find additional details in this thread in the linked post:

http://www.daz3d.com/forums/discussion/44176/P15/#652689

- - -

Update / Edit:

It seems a more specific solution could be:

An additonal 3Delight camera preset is added that switches between horizontal and vertical field of view as reference depending on if the user wants to render images in horizontal or vertical aspect ratio.

To put it different:

Mattymanx pointed out correctly that:

Have you noticed that if you start off at 1:1 and then adjust the width to be less then the height you will get no distortion?

If the camera reference system of the viewport is adjusted by 90 degree based on vertical or horizontal image orientation no more distortions will happen. In other 3D software that adjustment happens automatically based on the aspect ratio the user choose.

You can find the details in this thread in the linked post

http://www.daz3d.com/forums/discussion/44176/P30/#665971

- - -

2) Adding camera presets for other plugins so they can work more efficiently
My main assumption is that the current camera preset of DAZ studio was setup to fit 3Delight.
This means that now OctaneRender users have the same distortions because they use the exact same viewport.

To take your gasstation analogy:
DAZ studio is the gas station.
Fuel pumps are camera and viewport presets.

There is one fuel pump for 3Delight.
There is one fuel pump for OctaneRender.

Currently OctaneRender users are forced to use the 3Delight fuel pump and get all the negative consequences that come with it included the distortions.
I paid for a high end race car and want to have my high octane gasoline. I really do not want that diesel the 3Delight fuel pump is delivering.

I completly agree that it would not work for 3Delight users to use the OctaneRender, LuxRender camera presets.
But I hope you can see that the reverse is also true. It does not make sense at all for LuxRender and OctaneRender users to use the same camera presets that were intended to be used by 3Delight.

My suggestion was to add camera presets for each render engine to be used by only that render engine the camera preset was intended for.

You can find additional details including screenshots in this thread in the linked post:

http://www.daz3d.com/forums/discussion/44176/P30/#665834

- - -

3) Provide workarounds to calculate the proper focal lenghts by giving access to the hidden parameter Field of View

With the help of formulas it is possible to calculate the proper values to be used in DAZ Studio.

http://www.tawbaware.com/maxlyons/calc.htm#fov_calculator

A photo camera uses a diagonal Field of View.
RenderMan's Field of View is measured across the narrower of the
two sides of the image.

I assume that the horizontal and vertical Field of View paramters are also used in DAZ Studio but hidden away.
I suggest to give access to the Field of View parameters in the DAZ Studio camera tab.

So why is that horizontal field of view parameter not included in the DAZ studio camera settings? :question:

I suspect this is not a limitation of RenderMan or 3Delight but indeed a choice by DAZ.

Speculation:
They may have hid away the horizontal Field of View parameter in order not to confuse the more hobbyist user base of DAZ Studio.
But if the field of view parameter is actually used in calculating the viewport it really should be possible to unhide that parameter and make it accessible for advanced users in the DAZ studio camera tab.

You can find additional details in this thread in the linked post:

http://www.daz3d.com/forums/discussion/44176/P30/#665800

- - -

I hope this entry now summarized everything properly so it is easier to make a difference between those three issues and their possible solutions.

I hope you can see the common idea behind each of the suggestions:

Provide additional functionality by adding additional presets and parameters in addition to the existing ones.

That way all users who are not interested in any advanced solutions can keep working with the default presets and parameters they allready know.

Mattymanx

Have you noticed that if you start off at 1:1 and then adjust the width to be less then the height you will get no distortion?

linvanchene

Feature Suggestion:
Adjust the camera reference system of the viewport 90 degree based on vertical or horizontal image orientation

Update / Edit:
or

Field of View is measured across the wider of the two sides of an image

When rendering images with horizontal aspect ratios
- a horizontal Field of View is used.

When rendering images with vertical aspect ratios
- a vertical Field of View is used

Mattymanx said:

Have you noticed that if you start off at 1:1 and then adjust the width to be less then the height you will get no distortion?

The short answer is yes.
The long answer is I did notice that it is happening but I only started to understand why it is happening after Hole posted the link to the RenderMan documentation.

I knew that some 3D software adjust the orientation of the reference system of the viewport cropping by 90 degree based on if the user wants to render images at horizontal or vertical orientation.

Before Hole posted the RenderMan documentation I did not know that such an adjustment is actually included in the RenderMan specs.

- - -

The reference system RenderMan is actually using is:

In photography fov is measured across the diagonal of the film plane, while in RenderMan it is measured across the narrower of the
two sides of the image.

Source: http://www.fundza.com/rman_booklet/advanced_camera.pdf

(Again, thank you hole for providing that source of information.)

If we are to trust what is written in that RenderMan documentation the reference system for the cropping of the viewport should change depending on the narrower side of the two sides of the image. :exclaim:

This could mean that instead of horizontal field of view vertical field of view is used.

What I was not able to figure out is:

Does RenderMan also include some specs to actually adjust the complete reference system when switching from horizontal to vertical aspect ratios? :question:

If you have a horizontal landscape image in theory the reference system could adjust so there are no distortions in the landscape image.
If you have a vertical portrait image in theory the reference system could adjust so there are no distortions in the portrait image.

- - -

What I can observe is in DAZ Studio no matter if I enter an aspect ratio of 2x1 or 1x2 the reference system of DAZ Studio remains the same in a way that everything is fit between the upper and the lower border of the asumed image plane.

The result of this is:
At vertical image orientation no distortions happen.
At horizontal image orientation distortions are visible.

What could actually happen to prevent the distortions is to rotate the reference system by 90 degree when the user wants to render an image in the horizontal aspect ratio.

Then the left and right image boarders should remain constant and the cropping happens on the top and the bottom.

In real life you make the same adjustment when you rotate your photo camera 90 degrees depending on if you want to make landscape or portrait images.

To summarize this the main difference between DAZ Studio and other 3D software is that
- in other 3D software there is a solution to adjust the camera system when the user switches between horizontal and vertical camera orientations.

- - -

The question now are:

Is there a way to adjust the complete camera system based on vertical or horizontal aspect ratios included in the RenderMan specs?

- - -

As I tried to achieve with the previous suggestions I see the solution not in changing the way the current system works but in adding additional features that gives interested users more advanced options.

So to stay in that way of thinking my solution would be:

An additonal 3Delight camera preset is added that switches between horizontal and vertical field of view as reference depending on if the user wants to render images in horizontal or vertical aspect ratio. :exclaim:

This means that all users not interested in such a solution can keep using the default DAZ camera preset that does not change the reference system by 90 degrees when the users switches from vertical image orientations to horizontal image orientations.

Update/Edit:
After everything that we discussed later this would mean that:

When Field of View is measured across the wider of the two sides of an image
almost no distortions are visible when rendering images at extreme aspect ratios.

When rendering images with horizontal aspect ratios
- a horizontal Field of View is used.

When rendering images with vertical aspect ratios
- a vertical Field of View is used .

You can read about this here:

http://www.daz3d.com/forums/discussion/44176/P45/#666832

- - -

I added another series of screenshots. This time the width is kept constant at 360 pixel.

Aspect_Ratio_1x1_360x360_rendered_in_OCDS
Aspect_Ratio_2x3_360x540_rendered_in_OCDS
Aspect_Ratio_9x16_360x640_rendered_in_OCDS
Aspect_Ratio_1x2_360x720_rendered_in_OCDS
Aspect_Ratio_1x4_360x1440_rendered_in_OCDS

But what you can observe is that it is not the width that remains constant.

In fact the height of the viewport remains constant as when we were rendering images with height constant at 360 pixel.

Mattymanx

Below the first image is the diagram from page six of the PDF file Hole linked to. You will see a diagram showing the FOV in Renderman versus a real world camera. The paragraph states "In photography fov is measured across the diagonal of the film plane, while in RenderMan it is measured across the narrower of the two sides of the image." If you look at the diagram you see that from the top to the bottom is the narrower distance so Renderman is calculating FOV based on that distance.

The second image is from the 3Delight manual - http://www.3delight.com/en/uploads/docs/3delight/3delight_26.html - bottom of 5.1.1

The third image is from page 20 of the RISpec 3.2 manual from here - http://renderman.pixar.com/view/rispec

Each showing the default values for the camera. According to those tables, 640x480 is the default image resolution. So that means that FOV is being calculated based on that default value. This explains why we see distortion when the width of the image is greater than the height but not when the height is greater than the width.

So the cameras in DAZ Studio follow Renderman specifications.

linvanchene

First, thank you for helping in figuring this out.

In photography fov is measured across the diagonal of the film plane, while in RenderMan it is measured across the narrower of the two sides of the image.

If you look at the diagram you see that from the top to the bottom is the narrower distance so Renderman is calculating FOV based on that distance.

Yes but unfortunately the image only shows one case of the two possibilies.

If you have a landscape image with horizontal field of view:
- the narrower of the two sides is the height of the image.
This case is shown in the manual and in the image you posted.

If you have a portrait image with vertical field of view:
- the narrower of the two sides is the width of the image.
This case is not shown in the manual.

What I took from that is:
RenderMan has two different ways to calculate Field of View.
RenderMan calculates field of view differently if the user selects a horizontal landscape format or a vertical portrait format.

- - -

Mattymanx said:

So the cameras in DAZ Studio follow Renderman specifications.

All I can say and also observe seems to be that Field of View seems to shift when we move from a horizontal to a vertical camera position.

But yes I have not found a reference anywhere that put me in the position to say if now RenderMan specs offer a solution to automatically adjust for the different ways Field of View are caluculated or not.

If it has no such functionality included then it really is true what you are saying.

DAZ Studio, 3Delight are working as expected in the reference system of RenderMan.

The second image is from the 3Delight manual - http://www.3delight.com/en/uploads/docs/3delight/3delight_26.html - bottom of 5.1.1

The third image is from page 20 of the RISpec 3.2 manual from here - http://renderman.pixar.com/view/rispec

Each showing the default values for the camera. According to those tables, 640x480 is the default image resolution. So that means that FOV is being calculated based on that default value. This explains why we see distortion when the width of the image is greater than the height but not when the height is greater than the width.

There is some small print under the pixar Table 4.1:

* Interrelated defaults

They could have taken any other pixel dimensions but the reason they took 640x480 was probably because that was the most frequent aspect ratios of the old 4x3 monitors that were used around 1990 when the first documentations of RenderMan were written.

- - -

What gave me some more information how RenderMan works was reading trough another online document:

https://renderman.pixar.com/resources/RPS_13.0/prman_technical_rendering/AppNotes/appnote.10.html

And there they say:

The first, and most obvious thing you might want to change is the image resolution. The default for resolution is determined by the output device.

or

For example, you may have heard that NTSC video “has a 4 to 3 aspect ratio

Both quotes at least to me give the impression that the default values you quoted were mere default resolutions used at the time of the original draft of the document.

More important seems to be that:

In practice, one or more of those values is probably not quite what you want for your application. The procedures described below change those values from their defaults to specific desired values, and, as mentioned above, such changes sometimes change the defaults of other values as well.

and last but not least

Crop Windows

Sometimes you want to generate only a small part of an image rather than render the whole thing. You could move the camera, zoom in on the section you wanted, and adjust the resolution, but that would be pretty complicated. Instead, it is very easily done with RiCropWindow. Setting a crop window does not change anything about the camera placement or viewing parameters. The only thing it does is indicate which subset of the normal output pixels you actually want rendered to the device. The crop window is specified as a fraction of the total image, rather than in pixel numbers, so that it is a resolution-independent value. The default is obviously 0.0 through 1.0 in both x and y.

So there is even a way to crop the default viewport.

We really should not have to render the whole image if we only need a small fraction of it.

- - -

Maybe the real issue is that it just does not seem to pay off for DAZ to provide such solutions if I am the only one asking for them.

I think all the puzzle pieces are now here.

Maybe if someone else with more understanding how RenderMan works reads trough it he can piece together some working solutions.

In any case thank you again to all those who helped in trying to figure this out. :coolsmile:

Hole

So there is even a way to crop the default viewport.

We really should not have to render the whole image if we only need a small fraction of it.

That's what I getting at by suggesting a script that uses the spot rendering function, define an area in the viewport and the script lets you define render dimensions larger than the viewport. It would probably be a bit hack 'n' slash if it's even possible but more convenient than rendering at 4K x 4k or whatever just to get an undistorted strip out of it.

SpyroRue

From what Ive read and seen here, I gather that the issue of fish eye distortion is only apparent in landscape ratios. So would I be correct in thinking, the solution for now would be to tilt the camera 90 degrees and render landscape sideways? Renderman would theoretically treat it as portrait ratio.

EDIT: I gave it a shot, and matched the camera angle with a 90 degree tilt. This of course left me with the requirement to zoom out to get it all in shot. Its the same ratio 16:5 and 5:16, I didn't touch the Focal length, which remains default value in both test renders. I think its not viable since matching the shot is near impossible. I don't have Lux or Octane to test against them.

linvanchene

SpyroRue said:

From what Ive read and seen here, I gather that the issue of fish eye distortion is only apparent in landscape ratios. So would I be correct in thinking, the solution for now would be to tilt the camera 90 degrees and render landscape sideways? Renderman would theoretically treat it as portrait ratio.

EDIT: I gave it a shot, and matched the camera angle with a 90 degree tilt. This of course left me with the requirement to zoom out to get it all in shot. Its the same ratio 16:5 and 5:16, I didn't touch the Focal length, which remains default value in both test renders. I think its not viable since matching the shot is near impossible. I don't have Lux or Octane to test against them.

Thank you so much for helping in testing this.

You post also inspired me to try.

Step 1: 01 default orientation - original aspect ratio 1440x360

Our goal is to render an image at an aspect ratio of 4x1.
Focal lenght is 35mm.

- - -

Step 2 default orientation - adjusted aspect ratio 360x1440

To prepare for the rotation we first must adjust the aspect ratio of the image from 4x1 to 1x4.
At this point the first problem occurs. The field of view "jumps" to fit the now vertical aspect ratio into a upper and lower image border.

/Update / Edit:

This jump happens because DAZ Studio at the time of writing this post kept the viewport always between an constant distance between the upper and lower image border.

The images Mattymanx posted a few posts later show this behavior.

- - -

Step 3: rotated 90 degrees - adjusted aspect ratio 360x1440

If you would simply Z rotate the camera in the parameters tab by 90 degree the image would not much.
Instead you have to switch to the perspective viewport and use the rotation tool to click the blue circle.
Try to rotate until you hit 90 degrees. Actually quite an effort to hit exactly 90 when rotating manually because it keeps stoping at 89.7 or 90.6 degrees.

Now you will notice that even though the image is rotated by 90 degree it does not match up at all with the original selection.

Step 4: rotated 90 degrees - adjusted aspect ratio 360x1440 - moved camera back

Since simply rotating the camera by 90 degrees with the viewport rotate tool is not going to match up the image you will have to adjust further.

- Adjust rotation
- Adjust translation

Even though I tried it is hard to actually match up the image to the original selection.

Can you try to render an image that way?
Probably. Just get used to rotate your head sideways.
Or rotate the monitor whatever you prefer. ;-)

Mattymanx

linvanchene,

FOV is being calculated based on the default value of 4:3. Because that is the default value Renderman will always adjust FOV as if the height was the lesser distance because it is in the default value. Even if the width is less then the height, FOV is still being calculated based on the default value of which the height is less then the width. This is constant within the software, it does not change.

If you need further clairification on the RiSpec, why not contact Pixar since its their software.

Hole,

Not exactly what you are looking for but in case you did not know you can select the Spot Render tool and go to the Tool Tab and tell it to render to a new window. It will render within the current settings you have set in your advanced render options. This way you can eaasily re-render just a portion of an image instead of a whole image if you only want to re-render a small area to fix an issue.

linvanchene

Update / Edit:

How was the viewport and field of view calculated in DAZ Studio 4.6.3.52?

The script Richard posted a few posts later shows that currently DAZ studio is calculating the viewport based on a fixed "frame" distance of 35mm.

One side of the viewport is kept fixed at a distance in mm.
The other side of the viewport is calculated based on that distance also in mm.
Based on those values in the unit mm the angular field of view formula is calculated.

Fov = 2 x arctan ( d / (2xf))

The formula was posted by Takeo Kensei a few posts laters.

- - -

Nevertheless we did not know that at the time of writing this original post!

- - -

Mattymanx said:

linvanchene,

FOV is being calculated based on the default value of 4:3. Because that is the default value Renderman will always adjust FOV as if the height was the lesser distance because it is in the default value. Even if the width is less then the height, FOV is still being calculated based on the default value of which the height is less then the width. This is constant within the software, it does not change.

I still do not understand how you come to that conclusion.

In the linked Renderman Manual that you quoted yourself it says:

Statement A: Field of view in RenderMan is measured across the narrower of the two sides of the image.

You say:

Statement B: FOV is being calculated based on the default value of 4:3.

- - -

Under which assumption does statement B make any sense if you assume that statement A is correct.

Statment A says that Field of View is measured based on the narrower of the two sides of the image.

I still do not understand what unit the default value of 4:3 is even supposed to have?

4:3 of what? mm? pixel?

- - -

I attached a screenshot that shows how the narrower side of the image results in using both vertical and horizontal field of view depending on the orientation of the image.

Mattymanx

See this chart again from the RiSpec 3.2 manual

linvanchene

Mattymanx said:

See this chart again from the RiSpec 3.2 manual

You did not answer my question.

Posting that chart is about the same as making a snapshot of your current DAZ studio render settings and then posting it here.
That does not explain how Field of View is calculated.
It just shows what current settings your are using.

It clearly says on the table Camera Options.

What you have posted are possible options to use and not default values on which field of view is always calculated.

The main purpose of that chart is to show the users what kind of values they can enter.

I explained that allready a few post back when you originaly posted that chart for the first time.

There is some small print under the pixar Table 4.1:

* Interrelated defaults

They could have taken any other pixel dimensions but the reason they took 640x480 was probably because that was the most frequent aspect ratios of the old 4x3 monitors that were used around 1990 when the first documentations of RenderMan were written.

You could enter any other values in the fields marked with * and all the other values would adjust.

FOV is being calculated based on the default value of 4:3.

I still do not understand what unit the default value of 4:3 is even supposed to have? 4:3 of what? mm? pixel? Please answer that question I allready asked in my previous post.

Takeo.Kensei

Take the formula and calculate for a 135 mm film

Fov = 2 x arctan ( d / (2xf))

With d = 35 mm
f = what you specified in your camera setttings

The fov is on the lesser from the width./height

The focal distance is the only thing that will change the perspective. So if you want to correct distortion, correct that

Mattymanx

Renderman users NTSC (4:3 ratio) as its default base. Meaning that the distance between the top and bottom of the frame being the shorter distance is how it will judge FOV. Rendermand will never judge FOV based on the left and right side of the frame even if its the shorter distance.

Interrelated means that the default values are connected to one another.

linvanchene

Post for Support Ticket:
Is 3Delight for DAZ Studio using vertical or horizontal field of view
or both depending on the aspect ratio?

Thank you both for adding to the conversation.
Just to be clear about that:

I still do not know for sure how field of view is measured in 3Delight.

The short version is:
It seems to be as Mattymanx suggests.
DAZ studio seems to use Vertical Field of View all the time.

- - -

I am just trying to figure out how it works based on the information the internet and the documents linked in this thread provide.
The reason because I second guess what was written before is because I try to figure out based on what information everyone comes to his conclusion.

Mattymanx said:

Renderman users NTSC (4:3 ratio) as its default base.

[...]
. . . Interrelated means that the default values are connected to one another .

I still think you missinterpretate the purpose of that table - nevertheless the conclusion you draw may be right!

I still believe the main purpose is to show the users which parameters exist and give some example values they could enter and how they are connected.
If they would reprint the same document today the table could read:

Horizontal Resolution: 1920
Vertical Resolution: 1080
Pixel Aspect Ratio: 1
Frame Aspect Ratio: 16:9

- - -

Why do I believe that having a fixed aspect ratio of 4x3 is not the case?

In some of my early posts I explained that some real world cameras use a fixed sensor aspect ratio of 3x2 with a fixed sensor size.
Exactly because of that fixed sensor size there is no extreme distortion happening in your photo camera viewport.
Focal length and field of view are based on that sensor size and any cropping happens inside that default sensor size.

BUT as many others pointed out. This is NOT how it works with 3D cameras in 3Delight and RenderMan.
There is no fixed sensor size. There is no fixed aspect ratio.

All that is needed to calculate field of view is the formula Takeo.Kensei posted.

Takeo.Kensei said:

Take the formula and calculate for a 135 mm film

Fov = 2 x arctan ( d / (2xf))

With d = 35 mm
f = what you specified in your camera setttings

The fov is on the lesser from the width./height

The focal distance is the only thing that will change the perspective. So if you want to correct distortion, correct that

- - -

Mattymanx said:

Meaning that the distance between the top and bottom of the frame being the shorter distance is how it will judge FOV. Rendermand will never judge FOV based on the left and right side of the frame even if its the shorter distance.

I start to believe you are right about this.

This would mean DAZ Studio 3Delight is using vertical field of view as reference all the time no matter of the aspect ratio we selected.

When vertical field of view is used distortions seem to happen at extreme horizontal aspect ratios.

To compare:
As far as I understand OctaneRender is always using horizontal field of view and there the distortions seem to happen at extreme vertical aspect ratios. Nevertheless there is an Area Render to work around this when creating banners at extreme aspect ratios.

- - -
The document Hole posted and which we quoted some time may be true for RenderMan:

In photography fov is measured across the diagonal of the film plane, while in RenderMan it is measured across the narrower of the
two sides of the image.

Source: http://www.fundza.com/rman_booklet/advanced_camera.pdf

3Delight is based on RenderMan.

But this does not mean that 3Delight uses exactly the same reference system.

I stumbled upon a thread in the 3Delight forum that asks the very same question we seem to be stuck with

- Is 3Delight for Maya using vertical or horizontal field of view?

I am confused on how to work out the fov for a camera. I was using
fov = 2arctan((film width/2)/fl)
(in mm)
which is what maya uses for its angle of view.
Essential RenderMan says to use height, however if I export a camera from Maya, it is not using height, width or the diagonal. (with a defualt maya cam you get fov =42.1847)
the spec says that RM uses horizontal fov.

this is for another program, I was using maya as a base to compare vales of the same camera from the other application.
is using fov = 2arctan((film height/2)/fl) safe/correct?

using camera -q -vfv and camera -q -hfv returns 37.84 and 54.43 respectively (on default maya camera), which is different to what is written to the rib file (42.1847)
in the doc hfv uses aov = 2 * atan( fbw / (2 * f) ) which is the same equation i posted earlier.

any ideas on what is going on?

Source:

http://www.3delight.com/en/modules/PunBB/viewtopic.php?id=2115

You can read the rest of the thread written in 2010 yourself.

Speculation:

What I started to wonder Is the "other program" Pb is talking about actually DAZ Studio?
Is Pb a developer for DAZ Studio?

- - -

Summary:

It seems in RenderMan related engines there are actually three different ways used to measure field of view:

- horizontal field of view

- vertical field of view

- Field of View is measured across the narrower of the two sides of the image.
This means either horizontal or vertical field of view is used based on the aspect ratio of the image.

- - -

Earlier it was suggested to contact Pixar to figure this out.
Nevertheless I start to believe that this is a mute point.
Even if they suggest to calculate field of view a certain way it seems it is up to each license taker to implement the system how it fits best their specific software.

So the only people that actually should know how their camera system works is the DAZ development team.

Is 3Delight for DAZ Studio using vertical or horizontal field of view or both depending on the aspect ratio? :question:

Update / Edit:

I have now sent a support ticket to ask them.

I added some duplicate quotes and information so the support staff can find the relevant information in this post.
I added a graphic that shows all the possible ways of how to calculate field of view.
On the graphic you can also see a forth way to calculate field of view.
Field of View is measured across the wider of the two sides of an image!

Takeo.Kensei

After a little check, it seems Mattymanx is right. The fov is always vertical

linvanchene

Takeo.Kensei said:

After a little check, it seems Mattymanx is right. The fov is always vertical

Oky that seems established. Thank you all for the patience and valuable information you added.

For everything I write now I assume two things.

1) DAZ Studio 3Delight is always using a vertical field of view.
2) OctaneRender standalone is always using a horizontal field of view.

If any of those two statements is not true then everything I write now will not be true either.
But if both of those statements are true then everything I write now could also be true.
- - -

What I was able to observe was:

When Field of View is measured across the narrower of the two sides of an image distortions are visible when rendering images at extreme aspect ratios.

Theoretical examples:
When rendering an image
- with a horizontal aspect ratio of 10x1 (x:y)
distortions are visible when a vertical field of view is used.

- with a vertical aspect ratio of 1x10 (x:y)
distortions are visible when a horizontal field of view is used.

Practical examples:

DAZ Studio 3Delight seems to use a vertical field of view.
When rendering images at extreme horizontal aspect ratios of 10x1 distortions are visible
Nevertheless when rendering images at extreme vertical aspect ratios of 1x10 no distortions are visible.

OctaneRender standalone seems to use a horizontal field of view.
When rendering images at extreme horizontal aspect ratios of 1x10 no distortions are visible.
Nevertheless when rendering images at extreme vertical aspect ratios of 10x1 distortions are visible.

- - -

Possible solution: :question:

When Field of View is measured across the wider of the two sides of an image
almost no distortions are visible when rendering images at extreme aspect ratios.

When rendering images with horizontal aspect ratios
- a horizontal Field of View is used.

When rendering images with vertical aspect ratios
- a vertical Field of View is used.

- - -

At the moment I am just interested if in theory if we want to render images with the least amount of distortion we should always measure field of view across the wider of the two sides of the image?

Do you know any 3D software or render engines that are allready doing it that way?

Or did I asume quite a lot of things and this may not work that way?

Update / Edit:
Uploaded v1002 of the image.

Btw:
To make it simple:
red bar means there are distortions
green bar means there are no distortions

Mattymanx

Since images can say more then words I just wanted to help clairify how Renderman will always measure FOV in a scene regardless of image dimentions. This is a constant that never changes.

In each image, the green line is the distance Renderman is using to measure your FOV

Richard Haseltine

I don't know exactly what they are going to amount to, but if you look at the (carefully redacted) changelogs for the private beta, at http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log , you will see there are lots of entries reading "Work on rendering improvements [internal]" - that may well indicate that something is going to change in respect to this issue (there's also an interesting entry under 4.6.4.69 "Added render dimension override properties to DzBasicCamera" though again, I'm not certain what we can safely read into that). In the meantime there is a script in the samples for calculating the current FoV, which should help to make things more concrete http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/calculate_fov/start (I thought there had been a script earlier in the thread, but was thinking it was one of Casual's).

cwichura

Richard Haseltine said:

there's also an interesting entry under 4.6.4.69 "Added render dimension override properties to DzBasicCamera" though again, I'm not certain what we can safely read into that

If that's what it sounds like, it means they have finally implemented something I put in as a feature request a while back. It's absolutely moronic that the render dimensions are a global property of the scene. I have many scenes where I set up multiple camera shots, say one landscape and one portrait orientation. Those require different render dimensions, and are really a property of which camera is selected. So this sounds like we'll finally be able to set the aspect ratio of the camera at the camera level, rather than having to include "portrait/landscape/square/etc" in the name of each camera and manually reconfigure the dimensions on the render tab when switching between cameras.

linvanchene

Richard Haseltine said:

I don't know exactly what they are going to amount to, but if you look at the (carefully redacted) changelogs for the private beta, at http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log , you will see there are lots of entries reading "Work on rendering improvements [internal]" - that may well indicate that something is going to change in respect to this issue (there's also an interesting entry under 4.6.4.69 "Added render dimension override properties to DzBasicCamera" though again, I'm not certain what we can safely read into that).

Thank you so much for this update. Whatever they are working on it is good to read that they are working on something.
A part of me speculates that maybe that override is needed so the plugin developers can provide support to convert the DAZ 3Delight camera data into plugin camera data.

Richard Haseltine said:

In the meantime there is a script in the samples for calculating the current FoV, which should help to make things more concrete http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/calculate_fov/start (I thought there had been a script earlier in the thread, but was thinking it was one of Casual's).

Interesting timing!

I now just finally wrapped my head around how the formula

α = 2 arctan d/2f

is used differently in computer graphics and photography.

I allready spoted some familiar terms in the script but will need to have another look at how Studio does it tomorrow with a fresh pair of eyes.

Mattymanx said:

Since images can say more then words I just wanted to help clairify how Renderman will always measure FOV in a scene regardless of image dimentions. This is a constant that never changes.

In each image, the green line is the distance Renderman is using to measure your FOV

Update/Edit:

I am not quite sure yet how exactly but it seems that in DAZ studio currently some variable is always kept fixed and that may be one of the reasons why the green line or any scene object that is fit to match the upper and lower viewport border always is locked between the top and the bottom of the aspect ratio we select in DAZ Studio.

OctaneRender is using horizontal field of view.
There the image is kept at a constant distance between the left and right side of the viewport.

- - -

The script Richard posted seems to hint at that the way DAZ studio calculates the viewport may be updated in one of the next studio releases based on the script code:

// Declare working variables
var nFrameWidth;
var nAspect;

// If the version of the application is 4.6.4.70 or newer
if( App.version64 >= 0x0004000600040046 ){
// Get the frame (film/sensor) width of the camera
nFrameWidth = oCamera.frameWidth;

// Get the aspect from the camera
nAspect = oCamera.aspectRatio;
// If the version of the application is older than 4.6.4.70
} else {
// If the version of the application is 4.6.4.69 or newer
if( App.version64 >= 0x0004000600040045 ){
nFrameWidth = oCamera.frameWidth;
// If the version of the application is older than 4.6.4.69
} else {
// The frame (film/sensor) width is hard coded at 35mm
nFrameWidth = 35;

- - -

How is Field of View calculated in Photography?

I leave this calculation here so those of you interested in using the formula manual have an example.

It can get tricky very quickly.

You will find the math behind the calculations on those pages if you are interested in doing the math yourself instead of using a script.

Angle of view:
http://en.wikipedia.org/wiki/Angle_of_view

Trigonometry:
http://en.wikipedia.org/wiki/Trigonometry

Inverse Functions:

http://en.wikipedia.org/wiki/Inverse_function

and

http://en.wikipedia.org/wiki/Inverse_trigonometric_functions

The following callculations were done by me. Please tell me if you find an error. :P
I am quoting myself here. But I think it just looks better to have the calculations in a box to separate them from the comments. :lol:.

α = 2 arctan d/2f

Example:
35mm film camera with 2x3 aspect ratio sensor with 36mm width and 24mm height.
d = 36 mm for horizontal FoV
d = 24 mm for vertical FoV
The Horizontal Field of View is 45°.

Goal: Find out the Vertical Field of View based on a known Horizontal Field of View.
Step 1: We are first calculating the Focal Length f.
f= ?
Because of the horizontal FoV we take d = 36 and α = 45.

45 = 2 arctan 36/2f
45 /2 = arctan 36 / 2f
Because y = arctan x is per definition x = tan y we get

36 / 2f = tan 45 /2
f = 18 / tan 22.5
f = 43.46 mm

Step 2: Now we can calculate the Vertical Field of View

Focal Length f= 43.46
Because of the Vertical Field of View we take d = 24mm
α = 2 arctan 24 / (2 * 43.46)
α = 30.87

I also double checked with the Angular Field of View Calculator.

http://www.tawbaware.com/maxlyons/calc.htm#fov_calculator

Update/Edit:

Removed examples how other 3D software are calculating Field of View because they will just add more confusion to an allready complicated thread.

The important part is:

How was the viewport and field of view calculated in DAZ Studio 4.6.3.52?

The script Richard posted shows that currently DAZ studio is calculating the viewport based on a fixed "frame" distance of 35mm.

One side of the viewport is kept fixed at a distance in mm.
The other side of the viewport is calculated based on that distance also in mm.

Based on those values in the unit mm the angular field of view formula seems to be calculated.

Fov = 2 x arctan ( d / (2xf))

- - -

Have a look at a the screenshots of the script posted in the next post.

The screenshot shows the frame width and height values in mm that are used to calculate the field of view.

linvanchene

I received an answer to the support ticket asking

Is 3Delight for DAZ Studio using vertical or horizontal field of view or both depending on the aspect ratio?

The answer may be a surprise to those who followed this thread:

Sorry for the confusion. While tech support does help answer basic program questions, or report bugs to the development team, In depth technical knowledge is beyond the scope of what we provide.

With that said though I had a talk with our head developer and Daz FOV is calculated horizontally. On the forum thread there is a post by Richard that gives a script to calculate the FOV

August 28, 2014 14:30

The link to the script Richard posted:

http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/calculate_fov/start

- - -

All the pictures Mattymanx posted and all the testing I did seemed to point in the direction that the current version DAZ Studio 4.6.5.32 is still using vertical field of view.

- - -

Speculation:

BUT Support refered to the script that includes alternative calculations based on the next DAZ Studio update 4.6.4.70.
Because of that I assume that the answer of the head developer was based on the version of DAZ Studio that is currently in beta.

In that way the code lines we spotted in the script could be interpreted in a way that the future version of DAZ Studio will use horizontal field of view.

If that is the case I would welcome that update because it will bring DAZ studio closer to the way other software are calculating field of view.

This could also mean that the distortions user noticed when rendering images at extreme horizontal aspect ratios may be gone.

We will see how it works as soon as DAZ Studio 4.6.4.70 or newer is released.

- - -

@ Script:

I don't know exactly what they are going to amount to, but if you look at the (carefully redacted) changelogs for the private beta, at http://docs.daz3d.com/doku.php/public/software/dazstudio/4/change_log , you will see there are lots of entries reading "Work on rendering improvements [internal]" - that may well indicate that something is going to change in respect to this issue (there's also an interesting entry under 4.6.4.69 "Added render dimension override properties to DzBasicCamera" though again, I'm not certain what we can safely read into that).

In the meantime there is a script in the samples for calculating the current FoV, which should help to make things more concrete http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/calculate_fov/start (I thought there had been a script earlier in the thread, but was thinking it was one of Casual's).

Thank you A LOT to the persons who created the script!

And Richard again, thank you A LOT for posting it.

I would not have found it and more importantly not even thought to actually look for a script.

This will help tremendously when trying to render out images in DAZ Studio that have to match the viewport of other software.

Quick guide to the script Calculate_FOV.dsa:

- download the .dsa file
http://docs.daz3d.com/doku.php/public/software/dazstudio/4/referenceguide/scripting/api_reference/samples/rendering/calculate_fov/start

- place the script file Calculate_FOV.dsa in your runtime script folder

example:
My DAZ 3D Library\Scripts\Calculate FOV

- open DAZ Studio

- go to windows / panes (tabs) / Script IDE

leave the Script IDE tab open or attach it on the left or right side of your viewport

- In the Content Library tab browse to where you placed the script

example:
My DAZ 3D Library\Scripts\Calculate FOV

- click on Calculate_FOV.dsa

- browse to your open Script IDE tab

- in the script IDE tab select execute

- - -

Note:
Just clicking on the Calculate_FOV.dsa will not automatically open the script IDE tab.

- - -
- - -

Update / Edit:

- attached two screenshots

Focal lenght 35mm
one rendered at an aspect ratio of 1x1 the other at an aspect ratio of 16x9

- removed some observations on the current system
- - -

I guess we will have to wait and see how it looks like in 4.6.4.70.

No point in worrying about a system that seems to get changed with the next update. :coolsmile: