ViewCaptureToFile output differs

Rhino Rhino for Windows
1

Hi All,

I ran into the issue where an image captured @ let’s say 1600x1200 px is different than the same one captured @ 2x the size (3200 x 2400). I expected the 2nd one, after scaling 50% would match the 1st one, but no, somehow the lens is different and they are way off…

I don’t understand the logic why Rhino would do that - I thought as long s the aspect ratio is the same, the view crop/lens would be exactly the same. @SamPage - is there some lensing obscure magic I am missing on this one?

thanks,

–jarek

2

Hi @pascal

I did some more testing and looks like this is buggy - the Rendering keeps the exact same view when rendering the same aspect ratio but different sizes of the current view; as soon as the ViewCaptureToFile size is larger than the screen/view, the lens/image crop is off and differs from the smaller sizes/same aspect ration or the same exact render sizes.

To repeat:

  1. open any file or make a few boxes
  2. Render @ 1600 x 1200, save
  3. Render @ 4800 x 3600, save
  4. ViewCapture @ 1600 x 1200, save
  5. ViewCapture @ 4800 x 3600, save

The last ViewCapture should be different than the 2 renders and smaller ViewCapture (use wider lens camera)

–jarek

–jarek

4

Hi Jarek - thanks, I’ll check it.

https://mcneel.myjetbrains.com/youtrack/issue/RH-49951

Also this, discovered along the way

https://mcneel.myjetbrains.com/youtrack/issue/RH-49952

-Pascal

1 Like
5

Hi Pascal,

thanks - and to clarify why this is important (apart from pure logic) - for some parts or “elements” of the capture, it is important to do it in 2x size so the lines can stay thinner, or for ZDepth to actually have it AntiAliased (original size is not -AA-ed, but if you do 2 x size and then scale the capture by 50% it works nicely).

But in general, we would like to have the output predictable, just like the Rendering is.

–jarek

1 Like
6

Thanks Pascal, and nice catch with the 2nd one - I agree the settings should stay the same (keep pixel size and scale as entered, instead of multiplying the pixel sizes and resetting scale).

–jarek

8

Hi @jeff,

I have noticed fix for this bug has been slated for v7. In our workflows this discrepancy is a big deal…was hoping for a fix within v6 SRs cycle. Any hope for earlier fix? I guess we didn’t whine loud and long enough :wink:

–jarek

9

Are you sure about that?

1 Like
10

Great, now you are playing tricks with YT :wink: I will happily be wrong if it stays as 6.x !

11

You may want to try using the print dialog with destination set to image file to get your images as an alternative to ViewCaptureToFile.

12

Thanks Steve, I may try that but the main issue is this happens inside many of the scripted automated tools that rely on this command producing consistent output based on image proportions. Using this workaround would not help there. It used to work fine before, but I can’t pinpoint at what version this problem started happening…

–jarek

13

I’m just trying to find a solution that works for you now. I don’t know when or even if we will be able to fix this ViewCaptureToFile issue during V6 service releases, so it seems worthwhile to explore alternative options. If the print command version works, we may be able to figure out a way to have this be a replacement function for scripted automated tools that you are using.

14

Hi Steve,

I just tested this via Print dialog and can confirm than when the output is set to ImageFile, there is no issue that ViewCaptureToFile has (the same proportion views of different sizes cameras match perfectly).

I ran into problems when trying to see if that can be automated - the “command line” version of the print dialog is lacking many functions that dialog has, so I am not able to define the pixel sizes etc. and replace the scripted version of viewcapture with the print dialog…

Another issue I ran into “by the way” while testing (with Print Dialog) is if I set line width to 1 mm and Scale to 10, the output thick lines are weirdly jagged.

lines_scaling_problem
lines_scaling_problem1168×855 197 KB

I was looking into it to see if that could be an alternative to non-working line scaling in ViewCapture commands, and even the non-working workaround of using the OpenGLWireThickness to simulate it (it works nice for Edges but ignores Curves for screenshots). So - many options to try but neither of them works as a solution to the problem so far.
Unless somehow you can implement the Print viewcapturing method of scaling the view into ViewCapture command and fix the scaling problem ?

thanks for looking into that.

–jarek

15

Hey Jarek,
This issue is not going to be fixed in V6 as it has the potential to break other parts of ViewCapture. I do think we can solve this by getting a custom script that works for you as an alternative. Does the following python script provide the output that you are looking for?

import scriptcontext as sc
import Rhino
import System.Drawing

size = System.Drawing.Size(1600,1200)
view = sc.doc.Views.ActiveView;

settings = Rhino.Display.ViewCaptureSettings(view, size, 200)
image1 = Rhino.Display.ViewCapture.CaptureToBitmap(settings)
image1.Save(r"C:\capture1.png")

size = System.Drawing.Size(3200,2400)
settings = Rhino.Display.ViewCaptureSettings(view, size, 200)
image2 = Rhino.Display.ViewCapture.CaptureToBitmap(settings)
image2.Save(r"C:\capture2.png")
16

Hi Steve,

Thanks for the note and the sample script! It does the job for now (I tested many sizes outputs and they match perfectly). Since the tool that this bug is affecting is written in RhinoScript, I needed to run this Python code from inside RhinoScript, which actually worked quite well and I can even embed the python script as RhinoScript function, no need for a separate .py file.

thanks again-

–jarek

17

hi @stevebaer,

I ran into two issues with this workaround:

  1. this method seems to ignore any curve/edge thickness settings - always captures @ 1 pixel wide
  2. no matter what dpi setting is used, it always saved @ 96 dpi

Do you see these shortcomings on your end ?

thanks,

–jarek

18

Try adjusting the print width for the objects

That is extended information for an image. You may be able to set this in the script by calling
image1.SetResolution(200,200)

19

I need to be able to capture the view as-is, with mixed display modes and various curve/edge/mesh edge widths. Setting up print widths would not cut it. The scenes can have 1000s of objects with mixed display modes. Trying to solve it with print widths is a coding nightmarish solution. Does this python method ignore any display thicknesses by default? Unfortunately if the thicknesses are ignored this workaround is not helping much, sorry.

image1.SetResolution(72,72) works well, thank you

20

I’ll see what I can do about this. It may be more achievable than the original issue
https://mcneel.myjetbrains.com/youtrack/issue/RH-51407

21

Hi Steve - thanks! To clarify, the issue now is not even wire thickness scaling as much as recognizing the wire thickness. In case of captures of mixed curve/edge thickness viewports, they all come out as 1 pixel, no matter what the thickness on display is. So for example if I have curves @ 2 pix, edges @ 1 pix and some per-object display modes with curve thickness @ 3 pix, they would all capture @ 1 pix.

Obviously scaling these proportionally would be a plus, if achievable, but I remember a while ago you said it is not easily achievable and was slated for future releases.