SU camera match tool shows wrong camera orientation values

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


@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.)

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.

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.

What I found just right now.

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,


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?

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…


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

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

So are there any ideas?

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…


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

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

Where/how are you getting your values from SketchUp?

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

Ah. That’s where ACT comes into play.


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…)

he is looking at the ACT statistics shown on the screen after he uses Match photo…

I tried to use the API to generate the same set as those, but could not find a way of ‘matching’ ACT’s result for ‘Roll’…

I can also not find a way of generating the OP’s expectations for tilt or roll…

have a look at the scenes in his second upload…


Yes, the problem is with ACT reports wrong values. If the image plane was a square (aspect ratio 1:1) the problem is going to be the same with ACT values given after Matching photo tool.

Cropping an image to square aspect ration will only make changes for horizontal FOV. So the main other values of the perspective in my drawing are as before (vFOV=120°; x=20°; z=30°) but SU still shows us previous wrong values.

So what’s the result of this discussion?)

Match photo works great and the coordinates don’t actually have any impact on workflow.

the OP’s example skp’s show that ‘Match photo works’, so that is not the issue…

the OP’s issue is with their workflow invoking ACT’s camera statistics…

if your workflow needs those statistic’s for reporting, rendering, storey boarding, …etc, then you may also consider any inaccuracy an issue…

understanding the exposed inaccuracy may have impact in seemingly unrelated areas…