Image File Support in Rhino 5

Rhino 5 supports the attachment of image files in the BackgroundBitmap and PictureFrame commands.

Rhino works best with image files that are “power of 2” in size.

This is because Rhino displays image files as textures - always.

To display a file as a texture, Rhino uses OpenGL to texture map a polygon or polygon mesh. This is important information for many reasons:

1. OpenGL stores textures in GPU memory.
2. Because of #1, OpenGL implementations have hardware requirements (limitations) on how big a texture can physically be.
3. Because of #2, there is no standard maximum defined size for a texture. It's based on your video card and drivers.
4. Because of #3, Rhino can't just use any file at any resolution and assume it's going to work.
5. Because of #4, if Rhino encounters an image file that does not meet your video hardware capabilities, it must resize the image to a size that can be used by your hardware.

It is not a requirement for Rhino 5 that image files be exactly sized to a power of 2.

But, the internal representation in Rhino (and thus for OpenGL) is a power of 2. In other words, you can throw any file or texture at Rhino 5 and it will make sure it works on most video hardware.

So how does it make it work if the image is not a power of 2?

If Rhino needs to resize an image, it will resize it to the next highest power of 2 that is greater than the current dimensions but less than or equal to the maximum dimensions supported by the current hardware.

Here are a few examples to illustrate this. Assume the current hardware's texture size limitation is 8192 x 8192. If Rhino sees a file with dimensions:

• 256 x 256 - Rhino will do nothing, perfect powers of 2.
• 1024 x 1024 - Rhino will do nothing, perfect powers of 2.
• 1024 x 256 - Again, Rhino will do nothing, perfect powers of 2.
• 127 x 127 - Rhino will resize the image to 128 x 128, next highest value that is a power of 2 and greater than the current dimensions.
• 129 x 129 - Rhino will resize the image to 256 x 256, again, the next highest value that is a power of 2 and greater than the current dimensions.

Rhino will never downsize an image because that's a lossy operation. So it will always increase dimensions and never decrease them, except in the following cases:

• 9000 x 6000 - Rhino will resize (downsize) the image to 8192 x 8192. 9000 exceeds the 8192 maximum limitation and 6000 isn't a power of 2. The next available power of 2 is 8192.
• 9000 x 9000 - Rhino will resize (downsize) the image to 8192 x 8192. Both dimensions exceed hardware limitations and are adjusted to the maximum limits.

When Rhino does resize the image, it does not use any kind of sampling or bi-linear filtering. It is a straight linear stretch or shrink. So, if the difference between original dimensions and adjusted dimensions is greater, the results look worse.

Take the 129 x 129 example above. Rhino basically has to double the size of the image resulting in every pixel now being a 2 x 2 block in the final result.

This is the major cause of pixelization in the display of the attached image.

But, the results can even look worse if it tried resizing to 128 x 128. Banding can often occur because entire rows or columns of pixels have been removed.

Rhino will not downsize anything unless it absolutely has to due to hardware limitations.

Always keep images as close to values that are just less than powers of 2 as possible. And if you can, try to make them powers of 2.

Given today's video hardware, the two limits we see most of are 4096 x 4096 and 8192 x 8192. So if you're generating large textures, those are the dimensions to which you should limit your image generator.

Making them any larger is a waste of time, space, and will cause Rhino to throw out a lot of good pixel information.