Dots per inch, Printing

What is the workflow you are actually doing? What are you trying to print, and from what? Which print dialog? Is it even in Rhino? Seriously, you’re not being clear.

1 Like


1 Like

I just checked Ver.6 (Yes WIP, I understand) It also is not writing the correct dpi to the EXIF data while creating a *.tif image file…

I filed the issue as RH-41060.

@stevebaer, we actually do write that information. See the YT issue for information.


Spot on!

Thank You, much appreciated

But what print dialog dpi is being referred to? The Print command for linework has nothing to do with renders, and the Print function in the render window is some bog-basic tool that has no settings, it’s all up to the printer driver. So where exactly is “Rhino” not “printing” renders at the “right” scale? Seriously, please explain, preferably with screenshots.

Screen shots are above…If I tell my printer to print this at 100% it will come out at 83" x 83" not the 20 x 20 I specified, and I don’t want to calculate in my head the proper reduction percentage. if this worked the way it should it would come out the printer at proper size with NO post processing…

I think what is happening is this:
He prints his viewports directly to tiff-format, specifying desired print size and dpi. This results in a given dimensions in pixels (3800x2400 or similar). He then copies this file to a thumb drive, which is inserted directly into a printer. The file is then printed directly from the printer without a media size being specified, based only on pixel dimensions and dpi (ppi, rather). As Rhino doesn’t change the exif data, but leave them at the standard 72, the printer gives him a low-res - but huge - print. Right?

“without a media size being specified, based only on pixel dimensions and dpi (ppi, rather)” <-----Yes, kinda, I tell the printer !00% it then sees the the incorrect 72 dpi/ppi within the exif data of the image and the print size is way large!

The Resolution pull down menu in the print dialog has no effect on print dpi it is always 72
The 1 inch in model = 1 inch on paper has no effect either

entering a custom dpi has no effect it is always 72

Wow this seems a little out of hand for a simple seeming issue.
I tested on v5 for kicks. When saving images through the print dialog (File - Print), no matter what dpi I chose from the drop down list or entered myself, the resulting file was the proper pixel dimension but 72dpi every time. It’s a easy fix in photoshop, but it shouldn’t be a issue in the first place.

Well… again… no where in that dialog box does rhino claim to be asking for the EXIF data. Rhino merely asks you how big (measurable with a ruler) you want the picture to be and at how many pixels per unit this picture will be shown. Then Rhino saves you the trouble and calculates how many pixels it will need to render.

Is this the first time this issue is discussed? No, it pops up again and again.

Is it a bug? Well, since it’s by design, no.

Steve says that Rhino doesn’t set the EXIF and that Windows uses a default. Nathan says Rhino sets this value. I dunno.

Is that the best way / most user-friendly to go about this? Who knows. As you say - and has been said every time this comes up - the EXIF data is easily set in the application where you will be using this picture. Of course, when now a situation comes up where there isn’t another application used, it’s obvious that the current system doesn’t always work…

Any application that generates images and has a print function wants to know what default image size YOU want, therefore it needs two things from you: size dimensions ie inches, mm, miles angstroms, etc AND print quality/resolution/dpi(unit)/ppi without these two pieces of information there is no default size/resolution ALL windows print dialog will collect and use this info for Your albeit arbitrary default size/quality. Rhino is NOT doing this properly it ask you for print quality in three different places and uses it to calculate x,y pixel count but it is not applying the quality variable to the image and that is the dots per inch. If you choose 300 dpi it should NEVER be 72 in the image file. when you interrogate the image properties it should show 300 dpi and when printing at 100% 1 inch should equal 1 inch with however many dpi you choose.

And NO I don’t want to load every rhino print into an imaging program and set the dpi to 300 (that i already defined in Rhino) and save it out just so it will print the correct size, when the print dialog for Rhino is able to and WILL do this if it worked right…

If you create a 10" x 10" x 300 dpi image with rhino at 100% what size print would you expect the print to be???
I expect the image to be 10" x 10" x 300 dpi measured with laboratory test instruments!!! BUT it wont be!
It is going to be 41.6" x 41.6" at a supper low res of 72 dpi !!!

What is so hard to understand about Rhino will NOT print actual sizes as defined ???

What if Photoshop did this?? what about you word processor? do you tell these people to bring their file into another application in order to make it print correctly???

I recall that for many years, Photoshop DID do exactly this.
The EXIF value was not universally used. Photoshop ignored it and assumed 72 no matter what was set to or if it even existed.
Most people got used to calculating the resolution they needed based on the print size and their preferred DPI.
Then print to the desired size OR set the DPI to what you calculated and you’re off to the races.

If this behavior is by design, then the print dialog doesn’t communicate that well if at all.
The print dialog asks you to input a dpi, but it only returns a 72 dpi image. I think it’s fair to say that what most people would expect is a file in the dpi they input, anything different is understandably irritating.
It’s obviously shouldn’t be a priority issue, but it is baffling to me that’s it’s an issue in the first place.

i believe the point was made persistently clear for a while now, since its going to be changed what are you guys arguing for ever? seriously crack a beer and get something productive done instead of bashing a dead horse further. or go and do some workout, too many dots per inch can cause bulls diarrhea.


RH-41060 is fixed in the latest Rhino 6 Service Release Candidate

Thanks Brian!