Rhino 5 supports the attachment of image files in the [[http://​docs.mcneel.com/​rhino/​5/​help/​en-us/​commands/​backgroundbitmap.htm#​Place|BackgroundBitmap]] and [[http://​docs.mcneel.com/​rhino/​5/​help/​en-us/​commands/​pictureframe.htm|PictureFrame]] commands.

Rhino 5 supports the attachment of image files in the [[http://​docs.mcneel.com/​rhino/​5/​help/​en-us/​commands/​backgroundbitmap.htm#​Place|BackgroundBitmap]] and [[http://​docs.mcneel.com/​rhino/​5/​help/​en-us/​commands/​pictureframe.htm|PictureFrame]] commands.

\\

\\

+

**Rhino works best with image files that are "power of 2" in size.** ​

**Rhino works best with image files that are "power of 2" in size.** ​

\\

\\

+

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

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

-

===== Images ​Stored As Textures ​=====

+

===== Images ​stored as textures ​=====

-

In order 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:

+

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:

- OpenGL stores textures in GPU memory.

- OpenGL stores textures in GPU memory.

-

- Because of #1, OpenGL implementations have certain ​hardware requirements (limitations) on how big a "texture" ​can physically be.

+

- Because of #1, OpenGL implementations have hardware requirements (limitations) on how big a texture can physically be.

-

- Because of #2, there is no "standard maximum" ​size a texture ​is defined to be, and it's based on your video card and drivers.

+

- Because of #2, there is no //standard maximum// defined ​size for a texture. It's based on your video card and drivers.

-

- Because of #3, Rhino can't just use any file at any resolution and "assume" ​it's going to work

+

- Because of #3, Rhino can't just use any file at any resolution and assume it's going to work.

-

- Because of #4, If and when Rhino encounters an image file that does not meet a user'​s ​video hardware capabilities,​ it must resize the image to a size that can be used by the user'​s ​hardware.

+

- 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 a image files be exactly sized to a power of 2.//**

+

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

\\

\\

-

However, the internal representation in Rhino (and thus for OpenGL) __is__ 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.

In other words, you can throw any file or texture at Rhino 5 and it will make sure it works on most video hardware.

-

===== Adjusting for the Power of 2 =====

+

===== Adjusting for the power of 2 =====

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

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

-

//**If Rhino needs to resize an image, ​then 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.**//​

+

//**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.**//​

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//.

+

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 worse the results ​will look.

+

So, if the difference between original dimensions and adjusted dimensions is greater, the results look worse.

\\

\\

\\

\\

Line 47:

Line 50:

\\

\\

\\

\\

-

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

+

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

\\

\\

\\

\\

-

However, the results can even look worse if it tried resizing to 128 x 128. You can get "​banding"​ to occur in many cases because entire rows or columns of pixels have been removed. ​

+

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.//​

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

-

===== Basic Recommendation: ​=====

+

===== Basic recommendation=====

-

//**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**//

+

//**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 2 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. ​

+

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.//​

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