SU camera match tool shows wrong camera orientation values

[yuri_ch]

Hi! SketchUp camera match tool defines wrong camera orientation values. See the proof. I will use Photoshop to draw perspective scheme using trigonometry to check it.
So let’s have a rectangular canvas size like 2560x1440 (in pixels) and vertical FOV 30 deg. and so horizontal FOV will be 50,9 deg. Let it the level of horizon line be like x=20 deg. and also I will incline it to 30 deg (z=30 deg). Next, I draw a cube rotated to the camera on 45 deg. You can download my .psd document, I created here guidelines, contours, marked VP and MP (switch it on in Photoshop if it is turned off).

So now let’s try Sketchup matching tool. And we will see that SU defined x like -17.2 deg. and z 31.6 instead of x=20 and z=30. Or maybe I’m something missing up?

SU persp matching check.skp (535.2 KB) su camera reco check.psd (701.8 KB)

[yuri_ch]

Any ideas?

[john_drivenupthewall]

not sure what you are even trying to test…

I think, match photo uses a 2d camera with very complex matrix manipulation for eye, target and up…

it only works with un-modified ‘real’ images, and even cropping breaks the algorithm…

I’m not surprised if a .psd fails…

have you tried importing a 3d object exported from PS…

john

[yuri_ch]

My goal is to prove that SU shows wrong camera orientation values. We are having the true perspective image, we know it’s real parametres, we know where the centre of the canvas is placed and it has not been moved, cropped, etc. That means SU should show exactly the same values. And no matter what kind of application instead of PS to use, I draw this image using trigonometry and I’m sure there is no any mistake in my perspective drawing so that’s why I don’t understand why does SU show different values.

[yuri_ch]

For example FOV value is correct, I see that SU displaying a vertical FOV.

[john_drivenupthewall]

SU uses vertical fov until you set an aspect ratio, when it switches to horizontal…

for you skp file:

Two Point Perspective 
aspect_ratio: 1.7777777777777777 
focal_length: 67.31800173441556 
         fov: 29.939950421033643 
         eye: [514.1118343007296, -219.8992014284494, 132.69499372736806] 
      target: [72.06617666068244, 85.74816088322083, -33.901351501863545] 
          up: [0.09026989891500456, 0.5741150245926167, 0.8137833150703535] 
  dirrection: (-0.785644, 0.543225, -0.29609) 
 image_width: 0.0 
 center_2d.x: 0.12944291605805952 
 center_2d.y: -0.18776113672417902
       scale: 1.2716977900777722

john

[DanRathbun]

@yuri_ch, Just FYI … in the Ruby Console …

Sketchup.send_action 10624

… (on MS Windows) brings up this inspection dialog:
(Note that the specifications are for example, not your image.)

[yuri_ch]

Ok. Let’s have some more example of what I want to say. The same canvas 2560x1440 px. Now I’ll draw 3 point perspective image with next values:
horizontal FOV = 144°
vertical FOV = 120°
the level of horizon line 20°.
z tilt = 0°

So let’s see if SU match camera tool recognizes it correctly. Here are results.

As you can see it shows us the level of horizon line correctly (20°).
So now let’s do the same drawing with the same level of horizon line but for now, it will be tilted on 30° by Z-axis.

Here are the results from SU match tool

Do you see that now the level of horizon line showed as -17.2° and tilted on 31.6°? So that’s what I want to call a mistake in SU match camera tool. How can these values be true according to trigonometry? If let these values from SU be really true then we would get another representation of the perspective image but not this one.
Here is I attached full image with all visible VP if need.

[yuri_ch]

If SU detects VP correctly (and it really does it correctly) it must show the values correctly too. We’ve got an image with 2560x1440 and we draw it with vertical FOV 120°. So let’s find a place of needed position on coordinate system for the level of horizon line. 1440px/1,7321 (tan 60°) / 2 * 0,364 (tan 20°) = 151,30 px. So that is the place for the horizon line moved from the centre of the image to the top. But if we believe values of SU match tool then horizon line should be placed on 127,61 px from the centre to the top and if so then SU camera will no match the image any longer but it matches because we see on the screenshots that SU draws all the lines according to current perspective drawing.

[yuri_ch]

What I found just right now.

[john_drivenupthewall]

all your images are really hard to ‘read’…

can you set profiles to two in ‘Styles’ and grab the frame buffer…

model = Sketchup.active_model
view = model.active_view
options = {
  :filename    => "<-YOUR PATH->.png",
  :width       => view.vpwidth,
  :height      => view.vpheight,
  :transparent => false,
  :source      => :framebuffer,
}
view.write_image(options)

john

[yuri_ch]

Sorry for it’s difficult to read but you can download my images attached (that are not screenshots from SU workspace but «drawings”) and try to use match tool on your own machine to get the same I captured from my screen. Or maybe I didn’t understand you correctly and shall try to put your code above to SU ruby console or what?

[john_drivenupthewall]

if you setup your model, and paste the code into Ruby Console, it should give a better result than any screen grab…

you will need to add a path you want in the code…

or add a skp, already set up, like in the original post…

most people will only look if it’s really, really easy…

john

[yuri_ch]

Ok, thanks, I’ll upload .skp file a little bit later.

[yuri_ch]

Here is my .skp attached file.
3pp match tool test.skp (750.5 KB)

[yuri_ch]

So are there any ideas?

[john_drivenupthewall]

I have only just worked out the real question…

How does 'ACT' calculate camera roll? [the others data seems coherent]

‘ACT’ cameras report as being 2d Perspective and I can’t find a way of replicating it’s result for ‘roll’ using the API…

@tt_su may know as he wrote his extension which sets roll without an ‘ACT’ camera…

john

[tt_su]

@john_drivenupthewall

@tt_su may know as he wrote his extension which sets roll without an ‘ACT’ camera…

Camera Tool’s roll is just a rotation of the camera along it’s eye direction:

thomthom/camera-tools/blob/bd1db434b68aedc0826e7001551f595cf2f946aa/src/tt_camera/core.rb#L57-L67

@john_drivenupthewall

How does ‘ACT’ calculate camera roll?

How does Advanced Camera Tools come into play in this? Isn’t this related to the Match Camera feature?

@yuri_ch

And we will see that SU defined x like -17.2 deg. and z 31.6 instead of x=20 and z=30. Or maybe I’m something missing up?

Where/how are you getting your values from SketchUp?

[yuri_ch]

@tt_su

Where/how are you getting your values from SketchUp?

When click on “created camera” in scenes this window with values appears.

[tt_su]

Ah. That’s where ACT comes into play.

Hmm…

Is the issue that the camera is actually being positioned incorrectly in PhotoMatch? Or that ACT report an unexpected value? (The latter might be an issue with the extension. Or differences in how you compute your expected results. I’m not sure what happens when Aspect Ratio is enabled, if calculations use the viewport aspect ratio or the camera aspect ratio…)