Does the Power of 2 rule for image size have relavance for non animated Poser props?

512, 1024, 2048, 4096, 8192 Etc. 

 as far as I know the power of 2 is to make your comp more efficient! can use odd sized textures but will use more memory and be a likkle slower (depends on comp etc)

they should be SQUARE uv space only goes 0 to1 (have seen templates that ARE not square but internally they are square beware of that lol )

so for your Q can push your comp a lot harder for a single pic need more speed for any animations hope that's helped 

 The reason I ask the question is, I want to establish a pixel per foot texture density, so that I have the same relative pixel density for items of various sizes.

This however would make each texture a unique size. In other words, say I want 275 pixels per foot of texture and the surface Im texturing is 25 ft.

25 x 275= 6875 px 

This will work only if your models have flat UV's. Most models have UV mappings developed from the 3d shape and scale varies per location.

     Poser sets aside memory for textures in blocks of integer powers of 2, such that a 4000x2000 map takes a 4096x4096 block.  A 4100x2000 map would eat an 8192x8192 block, because the 4100 dimension exceeds 4096.

     That said, there's nothing wrong with making non-square maps for such purposes as consistent pixels per unit area.  Two things which you can do to optimize memory usage would be to size your maps so that the longer side is equal/less than a 2^integer value.  For example, for an 8:1 aspect ratio, you might make a 4000x500 map, or a 4096x512 map.

     You might also stack three or four such strip maps onto a single image, then use the image map node's scale & offset values to selectively apply the desired strip for each material.

Very useful to know. Thank you, seachnasaigh. :)

I thought 4000x2000 consumes 4096x2048 internally. Why do you think it has to be square? Mip mapping (in general) doesn't need square texture maps. I'm not saying I know otherwise - just asking.

Non uniform mip maps are called rip-maps.You will be hard pressed to find any GPU that supports them in any way....

You don't need a square image to mip map it, but the results will be stored square and have areas with non used information in them.

Mip mapping doesn't increase total memory consumption when using rgb, which many people do not realize. Throw in alpha, and memory consumption goes up.

Mip mapping can process less data and yet consume more memory, if that makes any sense.

See this. http://en.wikipedia.org/wiki/Mipmap

 "Why do you think it has to be square"   If that's to me I worded it badly lol, uv space is square and non square maps wastes space

to OP blender can let you do more or less what you want to do but learning blender just to uv map might be a pita!! I know one or two peeps that use this [ http://www.pullin-shapes.co.uk/page8.htm ] they say its great and easy to use

I was trying to be Socratic and ask a question that would cause people to think about what they're saying and why. That didn't work. I was asking for source - where did you get this notion that internally the mipmaps are all square? If I were writing the mipmap code, I would not inflate the shorter dimension beyond whatever power of two I need.

UV space is not square if the object in question does not use the entire UV space. Nor is the rendered space occupied by any given pixel necessarily square just because UV space defining the boundaries of an image is 0 to 1 in both dimensions. Consider my environment sphere, in which the equator (horizontal = U) is 0 to 1 but is twice as long as pole to pole (vertical = V). Despite both dimensions being 0 to 1, the best looking image map for an equirectangular image to be used as an environment is twice as wide as it is high - that is the only way to get a consistent apparent resolution near the equator. But this is beside the point I'm trying to get at here.

You guys are saying things that I, as a programmer, know are not required. Yes, there are hardware mipmaps that are always square but Poser is not using hardware rendering. It's entirely driven by the software. Further, the mipmapping technique in Firefly recently was improved (the new Crisp setting). This implies that it is even more modern than it was before, and there is no evidence that it can only mipmap square images into square images.

shvrdavid brought up ripmaps - I know what those are and I'm not talking about ripmaps. But since you raised the point, let's be clear:

I am saying that uniform image size reduction (mipmapping) refers to using a uniform ratio in both dimensions. That is to say if the starting texture is W x H, then each level of mipmapping is kW x kH, where k is 1/2, 1/4, 1/8, 1/16th, etc.

I am trying to make you understand then that a 2048 x 1024 image would then be mipmapped to 1024 x 512 at first level, 512 x 256 at second level, and so on. Each level has a uniform scale applied with respect to the original image. That is mipmapping and that is the meaning of "uniform":. It doesn't mean each mipmap is square - if the original is square, then each mipmap is square, but if the original is not square then each level is also not square, until one of the dimensions reaches 1. Then the other dimension shrinks until the last mipmap is 1x1, regardless of the original dimensions. 

On the other hand, non-uniform or anisotropic image reduction is called ripmapping. In a ripmap, the original W x H image is scaled with independent scaling factors k and j, such that reduced size images are produced at kW x jH, where k and j are 1/2, 1/4, 1/8, but independent of each other.

In ripmapping, square images become reduced to square AND non-square, and non-square images also become reduced to square AND non-square. In my original question, trying to get people to think for a second, I was not in any way asking about ripmapping. 

Furthermore, whether or not it is common or rare in GPU programming has nothing to do with Poser Firefly rendering.

Now - back to the question.

Please cite your source - what makes you believe that Poser software is written with an internal requirement to inflate texture data so that it is square? If it's because Stefan said so (author of Firefly) then I would like to read what he said. If it was some forum member who you're repeating, just say so. I want to understand where this notion came from.

As an example of the kind of answer I'm looking for, I will cite for you a source saying the opposite - that explicitly defines mipmapping on unequal dimensions:

This article from MSDN (http://msdn.microsoft.com/en-us/library/windows/desktop/bb206251(v=vs.85).aspx) says:

"Each surface in a mipmap chain has dimensions that are one-half that of the previous surface in the chain. If the top-level mipmap has dimensions of 256x128, the dimensions of the second-level mipmap are 128x64, the third-level are 64x32, and so on, down to 1x1. "

Now this isn't about Poser - it's about Direct X, so it doesn't count as declaring how Poser works.

Where does it say, about Poser, that internal mipmaps are all square?

Ok, make a frame buffer with OpenGl, and send it a 1024 x 1025 RGDA32F image. It should take just over 16 million octets to store it right???

Well, that depends on the GPU and the driver, some will force it to the next power of two (POT), and use 32 million............

Many drivers force this, and there is no way around it... It has nothing to do with what you program, it is a hardware/driver thing.

Some drivers force it square because it is far faster to process it that way on that particular GPU......... Or they want you to use another protocol entirely.

There are other hardware issues to consider as well.

ATI handles texture_2d completely differently than Nvidia, and sending non square textures with Mip Mips to them is asking for errors and driver crashes, guaranteed crashes on older hardware since the drivers require square mip maps. If you are compiling for all hardware, you usually force the GLSL compiler to omit texture_2d completely if non square textures with Mip Maps are going to be used. Or you use NPOT textures for everything, which cripples it on some hardware due to memory allocation issues when the driver forces POT allocation..

Programming and how the hardware handles it are different things.

Why are you talking about OpenGL?????? I made the assumption the thread is about Firefly.

Also you're confusing power of 2 (which I never disputed) with SQUARE.

Try to follow my point - power of two - sure. Square - no - that is not required.

Yes, I was referring to Opengl.

I get what you are saying, but you still have to display it as well. I guess it is possible that Poser stores everything twice,... One for display, one for Firefly

I have systems that use older (ancient) ATI hardware, and Poser works fine on them. So the OpenGl part of it has to be storing square mip maps.