Zooming out in Studio - Perspective Distortion
Melissa Conway
Posts: 590
I'm working on a large scene (with Stonemason's Urban Sprawl 2), where I have to zoom way out to arrange the buildings. When I use the Dolly Zoom (LMB + drag), my scene view perspective gets distorted. Any tips on how to avoid/fix that? Thanks!
Comments
- - -
Update / Edit:
To save you some time I remove speculations and point to the latest results of my testing a few posts down in this thread:
http://www.daz3d.com/forums/discussion/44176/#650265
- - -
The consequences of this are:
- Any distortions that normally happen with cameras are multiplied and cause the whole viewport to be completly distorted at extreme values.
- Images at extreme Aspect Ratio like 10:1, banners for websites etc. cannot be rendered in DAZ Studio because they are completly distorted.
- It is currently not possible to correctly composite together images rendered in DAZ Studio with images rendered in other 3D software.
- It is currently not possibe to correctly composite together images rendered in DAZ Studio with images captured by real world photography cameras.
The basic idea of any compositing work is that all pictures use the same focal lenght. If the focal lenght values are not calculated in the exact same way the images will not match up. :exclaim:
- - -
Update / Edit 2:
After about a month DAZ replied stating that everything is working as they expect.
http://www.daz3d.com/forums/discussion/44176/#652309
- - -
edited and removed by user.
I tried to give a long explanation how everything works but his only seems to distract from the main issue.
Have a look at the wiki page to get a better understanding how cameras work:
http://en.wikipedia.org/wiki/Angle_of_view
Ah. Okay then. LOL Thanks for the heads-up. :-)
Hopefully we'll see a fix in the next update of Studio, I'm amazed so few users have opened a ticket.
Its possible to compensate by increasing focal length, but it makes accurate camera settings a little meaningless. And as linvanchene points out, any composite work is compromised.
edited and removed by user.
I tried to give a long explanation how everything works but his only seems to distract from the main issue.
Have a look at the wiki page to get a better understanding how cameras work:
http://en.wikipedia.org/wiki/Angle_of_view
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?
parts edited and removed by user.
The big question for the long term is:
:question: :question: :question:
- - -
Screenshot attached:
Another image at a 10:1 aspect ratio with 35mm focal lenght selected.
Update / Edit:
Added another image at 5:1 aspect ratio with 35mm focal lenght selected
In both cases at least to me it is obvious that this is not an image a 35mm lens would produce.
Looks more like below 10mm lens...
I agree. With 50mm focal length it starts to become really noticeable at 2:1
Below:- The 31.59mm image is the same as the 50mm image.
Maybe the reason not many people have noticed this problem is because they don't use extreme settings. I almost exclusively use 16:9 and A4 letter. I've not noticed any distortion at 50mm focal distance. Nevertheless, if there is a problem with distortion then DAZ will fix it soon hopefully.
When I was setting up a big scene , once, I used a separate camera set way above it to get an overall view. You can have different cameras for different purposes and just leave your render camera where you want it.
Gus
what if you render with the Lux or Octane plug-in? distortions?
Yes.
I have encountered this, and wondered about it. I'd change aspect ratios and get different focal length features. Glad to know it is not just me.
I took some time to experiment with this.
One reason why we see distortions is the way DAZ studio currently crops the images. :exclaim:
- - -
How does DAZ Studio crop the image?
Compare attached image:
DAZ aspect ratio comparison v1001
At first I could not see any logic behind what is happening.
But then I started to render images with a constant height of 360 pixel.
Aspect Ratio 1x1 360x360
Aspect Ratio 3x2 540x360
Aspect Ratio 16x9 640x360
Aspect Ratio 5x1 1800x360
If you compare all those images you will notice that the overlapping parts indeed look exactly the same as should be expected.
But as described by many users after a certain point extreme distortions start to happen.
The rendered image seems to lie on a 180 degree sphere in front of the camera.
What I cannot quite figure out yet is based on what kind of formulas that "image plane" is calculated. :question:
Fact is that forumula causes distortions the closer the image gets to the edges of that 180 degree sphere.
- - -
How does a real photo camera crop images?
Attached to the photocamera is a lens with a specific focal lenght that captures the image.
The image captured by the lens drops on the image sensor.
The size and the aspect ratio of the image sensor define the maximum possible resolution and aspect ratio of the photograph.
This means the image captured by the camera cannot be larger than the image sensor.
Currently most photo camera image sensors use an aspect ratio of 3x2.
Nevertheless as you know most monitors use an aspect ratio of 16x9 which is much narrower.
If the user selects to capture images with a 16x9 aspect ratio not the whole size of the image sensor is used.
The resulting cropped image at a 16x9 aspect ratio is smaller than the default image at an aspect ratio of 3x2.
Still the user has the benefit that he can show the image on his monitor at full screen size without black borders on the sides.
Compare attached image:
Aspect Ratio Crop based on 3x2 sensor size v1001.
- - -
Still it is important to notice that various photo and video cameras may use different sensor sizes.
The size of the sensor is linked to the focal lenght.
If you use the same lens on a camera with a different image sensor size the actual resulting focal lenght will be different.
http://en.wikipedia.org/wiki/Angle_of_view
http://en.wikipedia.org/wiki/Image_sensor_format
To put it in other words:
If you use the same lens in combination with a different image sensor size the resulting field of view on the image will also be different!
- - -
What crop system are other 3D software using?
It seems other 3D software applications are simulating the 3D camera in a way that they give the user a choice to select the size of the image sensor. Some 3D applications also talk about "film size" instead of "image sensor size".
This is because before digital photography the image was captured by film and not by a sensor.
In addition it also seems that many other 3D software crop the image based on the "film size" or the "image sensor size" the user choose.
As a result the aspect ratio of the rendered image is also cropped inside the default image! :exclaim:
It is the same as with the photo camera.
The lens with the selcted focal lenght captures the simulated image in the 3d scene.
The aspect ratio of the image sensor will define the limits of the image.
If the users chooses to crop the image the crop will happen inside the default image defined by the simulated image sensor or film size. :exclaim:
- - -
How much work will it be to convert the DAZ camera system to industry standards?
It seemes many other companies of the industry have agreed on some common standards how to define cameras, how to simulate image sensor size and how to handle cropping of the images.
I cannot judge how different the system DAZ currently uses is from the rest of the industry.
What I can observe is:
DAZ Studio seems to use some kind of 180 degree sphere instead of a fixed image sensor size to define the aspect ratio. This way of cropping the image leads to distortions on the edges.
Other 3D applications give the user a choice to select a fixed image sensor size and crop inside that resulting image.
- - -
Again my suggestion would be to updated the DAZ camera system to be in compliance with the standards set in the Alembic spec:
http://www.alembic.io/
http://docs.alembic.io/python/
- - -
Seems DAZ is not willing to acknowledge that there is an issue with the DAZ camera system.
I received the following replies.
What I find most amusing is that 20 minutes after they sent the first reply another moderator jumped in to state that I have not replied yet and the issue will be closed.
Wow. I had to wait one month for a reply and after DAZ responds I have 20 minutes before they lock down the issue as resolved?
- - -
I make my answer also public:
I know that you are just the person forwarding the message so I try not to lash all my current anger and frustration on you. Be aware that everything I write is directed at the persons in charge and responsible for the current situation.
I expected that DAZ would at least be honest enough to admit that there are issues. I am aware that changing the current way the camera system works would have huge consequences and cause a lot of additional work. So I expected an answer that says:
"We are aware of the issues but we will need to adress them with the next major release in DAZ studio 5."
But now they are seriously insisting that everything is working as intended?
Facts are:
- - -
"The Alembic Exporter for DAZ Studio does NOT include export of camera data".
IF everything would be working as it should there would be no reason not to include camera data export. !!! :exclaim:
- - -
- If users render a scene in 3Delight, Luxrender or Reality with DAZ studio distortions are visible.
- If users render the same scene in any other 3D software even at those extreme aspect ratios no distortions are visible.
- - -
- The depth of field in DAZ studio is compared to any other 3D software completly unrealistic.
- F stop values in DAZ studio are completly unrealistic and go from F1 to F infinity instead of being limited to F1.4 to F22.
- Focal lenght values do not match up at all with the images at the same focal lenght rendered in other 3D software.
- - -
- DAZ Studio does NOT give the user the option to select an image sensor or a crop factor.
- DAZ Studio does NOT give the user the option to select Field of View
In other 3D software those variables are used to simulate a realistic image:
- The resulting field of view is dependant on the sensor size in combination with the focal lenght the user chose.
or
- The user is given the choice to select the Field of View based on a standard sensor size of a full frame 35mm camera.
or
- The user can select a crop factor in combination with a focal lenght.
- - -
If you prefer images as proof:
I attached the image
OctaneRender Standalone Streets of Asia 2 v1001 5x1 1800x360
there are no visible distortions at all.
While the DAZ studio version clearly shows distortions.
DAZ Studio Aspect Ratio 5x1 1800x360 rendered in OCDS
Even if you have no knowlege about photography a simple glance at both images should be enough to acknowledge that there is an issue. That entrance to the left should be a round circle not an oval. The edges of the buildings are slanted facing inwards...
- - -
My personal speculation is that the person who designed the DAZ camera system has for a long time stopped working for DAZ.
Now those persons still working for DAZ do not seem to have the knowledge to actualy fix the formulas.
This can happen. But please be aware that ignoring this issue now will only make matters worse in the future.
I allready alerted DAZ in Feburary 2014 about the issue that camera data is NOT included in the alembic exporter. It now has become very obvious that all those issues with the DAZ camera system are connected.
I cincerly hope that by the time DAZ Studio 5 is released DAZ will have had enough time to hire another developer who has knowledge how other 3D software are using real world camera values and formulas to simulate a 3D image in a realistic way.
I got a reply from Britney today on a help request (not alt all related to your camera hep request) saying basically the same thing: Since they hadn't received a response from me, they assume it was resolved and they closed it. The last update in the request was from DAZ, 11 days ago, saying that it was reported to the bug tracker. So, what response were they waiting on from me??? I wonder if something has gone haywire in their system again, like the last time when they arbitrarily closed a bunch of tickets by mistake. It is quite frustrating.
You are basically right and wrong. DS implements what is in 3delight which means Renderman's Standard
You're also making confusion : Alembic is no standard for camera or whatever. It is only a container like Obj, FBX etc...
It is on it's way to become an interchange standard but does NOT define how a camera should behave
And Octane is not a standard at all. It is just a renderer
DAZ won't aknowledge that there is a problem as everything is working like it should. See P33 of Rispec http://renderman.pixar.com/products/rispec/rispec_pdf/RISpec3_2.pdf and read everything about the camera. Every software implement some thing differently. You can't say there is a bug just because they don't do it the same way. DS camera is not realistic. That's all
What you should do is rather ask for a feature or plugin. With the documentation above and if you know how to to the calculations to get the camera you want, half the job is done
The other part is to convince DAZ or a developer to do it
This 1000x over. Just because the cameras don't function the way a particular user or subset of users thinks that they should does not mean that they are broken. Just because they function differently than other applications does not mean that there is a bug.
Different software packages implement things differently all of the time. Does 3Delight have a bug because it doesn't calculate light the same way octane does? No, absolutely not.
This is a feature request and not a bug. If you'd like to submit a feature request you are more than welcome to, but remember that feature requests != feature implemented.
I see what you mean. DAZ can only work with what Renderman provides.
I expected Renderman to provide a realistic camera solution. The document you provided is from 2005. Could be that it was updated in the meantime.
But in the whole document no mention of:
- Sensor / Film size
- Crop Factor
In order to provide a realistic solution at least one of those variables should be included in any formula.
http://en.wikipedia.org/wiki/Angle_of_view
update / edit: removed code that might influence the way this page is displayed.
- - -
Update/ Edit:
removed parts that will just lead to further pointless argumentation that will not in any way help to find a solution.
I hoped to get some insight explaining formulas how DAZ Studio currently calculates the values, focal lenght, sensor size, aspect ratio, depth of field, F-stop.
- - -
- - -
In any case a big THANK YOU to all those who figured out that distortions happend, those who helped in finding a solution and trying to explain why the things currently work the way they do.
The fact is, camera focal length is effectively reduced when using landscape render dimensions.
If this was 'expected behavior' we should also see a reduction in the camera focal length parameter.
Here's another perspective (pun intended) on the subject.
linvanchene mentioned a real (digital) camera with a physical image sensor that is 1:1. However many pixels it has in X by Y, that's it. When you ask such a camera to give you a 16:9 image, it crops inside the camera image processor engine (hardware) to crop the image. All the lens characteristics are the same, the image sensor is the same, the camera just crops, or discards pixels the user does not want in the final 16:9 image.
Consider this: When you ask Studio to give you a 16:9, or 10:1 or 20:1 image, you are effectively ADDING pixels at the side of the frame, changing the field of view. Studio compensates by mathematically adjusting your focal length to get those pixels in view. This results in the observed behavior of short focal length, or "fisheye" distortion. This gets worse the higher the aspect ratio. It may not even be linear. From a photographic point of view, this may not be correct, but from a render engine point of view, maybe it is. I can't solve that debate. It's also been said that the great thing about standards is that there are so many to choose from.
What about this as a solution? There is a way to make true stereogram renders using Daz Studio and other render engines. It's a camera system that automatically does renders from two camera positions such that the resulting pair of images can fool your brain into seeing a real stereo image, given the right hardware assistance (or crossed eyes, LOL). What I would propose is a panorama camera system for Daz Studio that automatically performs multiple renders on either side of your existing camera view using exactly the same focal length such that the images can be seamlessly stitched together into a high aspect ratio panorama image with no distortion.
Yet another solution: Pano Tools which takes an image from a fisheye lens and corrects it to rectilinear perspective in software. This may be the simplest, most immediate solution. Pano Tools are available under GNU Lesser GPL. (That means free...) With this software, it would seem you could take a distorted image and correct it.
http://en.wikipedia.org/wiki/Panorama_Tools
http://wiki.panotools.org
This statement alone shows how much you are missing the point I am trying to make.
The rest of the 3D industry is investing large amounts of money to start doing the basic things exactly the same.
The idea is that the user can open any scene in any 3D software and render an image looking exactly the same as far as geometry and camera position and framing are concerned.
The materials and shaders may always be different in each render engine but camera position and framing should be identical.
Collada, Alemibc, Otoys ORBX are all file interchange formats invented with the idea to make it possible to send complete 3D scenes from one software to the other. Each format offers a lot of improvments on the previous one.
The rest of the 3D industry seems to work together to make advanced scene exchange between different 3D software happen.
And now the official answer of DAZ is that they are not interested in helping their users benefit from that development?
The official answer from DAZ really is that they want to keep doing things differently all of the time?
- - -
Update/Edit: removed section that seems to distract from the core message I intended to deliver.
This is a feature request and not a bug. If you'd like to submit a feature request you are more than welcome to, but remember that feature requests != feature implemented.
Is that now the official answer of DAZ I was waiting on for a month?
I hoped that someone on the DAZ team that has advanced knowledge how focal lenght, F - Stop, Aspect Ratio, Field of View are calculated would provide some additional insight.
At least then those users who are interested to composite images together with other 3D software and real world photographs would have had some officially confirmed information how those formulas are calculated and which values we must use to multiply or add to get to the values used in other 3D software and real world cameras.
But instead you are pointing out that the mistake I made was to submit a "Bug Report" instead of a "Feature Request"...
- - -
Just to be very clear on that:
At this point in time I will not submit another ticket on this matter.
I invested A LOT OF TIME into this topic. Not only on this forum but also on others.
To me it is VERY important that I can use a software that uses realistic values.
I tried to reason, listed facts, tried to explain.
But I can see that I am probably alone with that.
DAZ seems not interested.
Now it is up to other users to start voicing their opinion if you care about this.
Here is the method I use to correct the error:-
Position camera using chosen focal length and 1:1 render dimensions, then save scene.
Open scene in a second window and set chosen landscape render dimension.
Increase focal length until second window matches the first window.
Edit:- This method is very accurate and effective in all combinations of focal length/landscape render dimension.
"The camera in DS acts in a similar manner to cameras in the real world, it is not truly a real camera and allows more extreme combinations than you can do with a physical camera but the behavior is, and has to be, similar. You get the same results with a real camera as you do with the Camera in DS with these extreme aspect ratios.
So what is done in the real world, with a real camera, is you take the picture and in an image manipulation software package of your choice you crop it to your desired aspect ratio, or you take several images and in your image manipulation software you composite them together.
Now there are likely some digital cameras out there where it will crop in the camera for you, similar to using image manipulation software, but that does not change the behavior of the Camera itself."
My ticket also had a similar response, and closed 20 minuets later. The response describes basic real wold properties of some cameras.
It does not address the issue at hand, Frankly, I think this issue is a big problem. I've spent literally thousands of hours on this software, only to find that the camera coding is erroneous.
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.
- - -
Feature Suggestion:
Add addtional camera preset to "cheat" around the way the viewport is cropped
Richard, thank you so much for your reply. :-)
It feels great to read that at least one person understood what we tried to explain with various examples.
Your suggestion seems to fit the issue perfectly.
It does not need to be a question of either option A or B
I can now see that my request to "fix" it was unfortunate in a way that it just triggered a defensive approach.
I can see that a feature request to add other alternative solutions how the viewport aspect ratio is calculated and cropped based on a specific image sensor size and how the resulting focal lenght and field of view are calculated is the more reasonable approach.
The optimal solution indeed seems to be to move in a direction in which the user can choose between several interface presets
- each with their own independent system how variables related to the camera system and the aspect ratio are calculated
- that match the requirements of the render engine the user is using.
- that match the personal preferences of the user
- - -
To me it seems interests of at least four different users groups can all be considered at the same time by providing separate presets.
- Casual DAZ 3Delight users may be happy with the current system and do not want anything to change.
- Experienced DAZ 3Delight users with a background in photography may prefer an updated system
that offers an alternative way to crop the viewport in a way that no distortions are happening
that offers a corrected calculation of the Focal lenght values that matches the alternative way the viewport is cropped
that is based on a specific sensor / film size or a defined crop factor
that alternatively offers the use of the variable Field of View instead of Focal Lenght
- Luxus and Reality plugin users may be happy about a preset that crops the display and calculates the camera values in ways that benefits the way Luxrender works
- OctaneRender plugin users may be happy about a preset that crops the display and calculates the camera values based on the way the OctaneRender standalone and the announced Cloudrender edition work
If we go the way Richard suggested and add additional interface presets that offer alternative ways how the variables are calculated everyone could be happy and use the same software without negative consequences for any other user group.
- - -
I do not know if the plugin developers of Luxus, Reality and OctaneRender can on their own access, alter and override the code how the DAZ viewport is displayed and if they can access directly variables like focal lenght in DAZ studio.
I assume that some parts like the calculation of camera values can be coded directly by the plugin developers. Other parts like the viewport crop presets may need to be provided by DAZ.
My suggestion would be that DAZ and the 3rd party plugin developers have a look at this undertaking together and then deceide on the best way to implement this feature.
- - -
Nethertheless, as mentioned, I will not press this issue further at this point in time.
I find it is very important that other users now add their voice and file feature requests on what ever option they find the best solution for their needs.
If you frame something in the view port using one aspec ratio and then switch to another aspect ration you will see that the top and bottom of the frame remain in position maintaining your original framing, focal distance and focus. The distortion that occurs is due to the angle of view being adjusted to compensate for the adding or removing of pixels on the sides. This is the exact same thing that occurs in a DLSR camera when your camera has a fixed position and you are using a zoom lens. The same image taken at 35MM will appear much more distorted then the image taken at 70mm even though the focal distance and focus has not changed. The main difference being that DAZ Studio (3Delight) is not restricted by the size and make of a camera sensor or by the limitations of a camera lens. If you want to avoid the distortion then the easiest way is to render everything 1:1 and crop when its done.
Either camera focal length or render engine angle of view. Mixing both is obviously wrong.
I think I'm seeing the same thing with a request I opened, then was asked to move one part of the ticket to a new ticket. In two months that ticket was not responded to, the original ticket is marked with a "waiting for response" and I responded months ago with the link to the new ticket. WHAT THE WHAT?!?!?
I'm also not a fan of the removal of collaborative input in the tracking system. I have no idea if anyone has logged a similar ticket or has some insight into what I experiencing with bugs offering a work around while I patiently hope the report is viewed and the bug is addressed in future releases.
In my experience I can usually asses who I'm dealing with by the name and so called sex. EG.
Dave Iceman:-Well slow, "what do you mean" X 10
Trish Dublin:- Sympathetic, "nothing I Can do"
Apply to all on line help.
Anyway. The focal length/landscape render dimension fix is at post #22.
It works, and is very accurate.