[WIP, not final render, still working on skin displacement, lighting and eyes.]

What works and what are the tradeoffs in reducing the size/weight of a texture.

Lets say I purchase a texture pac for Miki, and the head texture, when opened in 2D at 72 DPI is 3000 wide by 1915 high, and the file size is 1332K. Additionally, there is a bump map! it weighs in at 1179K.

Now, I am rendering to a frame size of 720x540 and moreover the actual 'real estate' taken up by the head of my character is probably less than 1/2 the frame, as in the example above.

This is a close-up; I do NOT want to lose quality. What strategies for reducing these maps work? Scale down the image map? Simply make a new JPG at the same size, but at 70%/80% quality, which results in a smaller file size?

::::: Opera :::::

scale at twice the dpi whenever possible. Do not reduce the quality. Generaly speaking, even for close ups, I very rarely go over 1024 in the largest dimension. In a situation such as your example, I might get iffy and run around 1536 or so.

wait...ynsaen that went over my head..... please explain "scale at twice the dpi" does that mean that since the width of my render is 720, I should scale the texture down to 1440 wide, but save out to a 100% jpg? ::::: Opera ::::

BTW the texture in use here is "Gizelle" for Miki by ExprssnImg

dpi of the texture. If your base texture is 72dpi, you will reduce the size by half but at a dpi of 144. Its not always possible to do, so you do have to lookat the result, and if it doesn't fly, then simply cut down the size.

http://www.renderosity.com/messages.ez?ForumID=12356&Form.ShowMessage=2594162&Reply=2594394#7 scroll to post 7 and whether a texture is 1025, or 1507, or 2048 i seem to remember something about poser treats it as a 2048 texture, atleast memory wise, could be very wrong just something i thought i read in forums here btw, my post, was for maps making small changes the smaller effect a map gives, the smaller a map can be such as skin tone, you choose a skin color, and the tone map varies it between 95%-100%, 256 map size works great

I am now totally confused. For instance, when I attempted to open the Gizelle head texture in my 2D program, I got the alert "The current image resolution is 2 pixels/in" and asking me to indicate how I wanted to open it. So, I said 72 pixels per inch. This yeilded an image at 72 pixels/in of 3000 wide by 1915 high, just as promised by the vendor. My program is telling me that "inches" equiv is 41.67 inches by 26.60 inches. So, what is the "dpi of the texture" or the "base texture?" 72? 3000? It sounds like you are suggesting I scale the image down to aprox 1500 wide, but then save out to 144 DPI? Is that correct? And why is this a good thing? Thank you, ::::: Opera :::::

I just tried the following: I scalled down by 50%. I did not render that out into 72 DPI, I left it at 144 DPI I tried saving as a 100% jpg at those settings, but the file size got BIGGER!

saving at 100% is telling it to not compress it, may as well be .bmp which is fine accually, poser has to uncompress any file used so cost to you should only be hd space

If you take a JPG, alter it and resave it it will lose image quality! You're better off using an uncompressed format - TIFF, for example. "So, what is the "dpi of the texture" or the "base texture?" 72? 3000?" In this example, the texture consists of 3000 pixels in width by 1915 pixels in height. DPI merely is an indicator (to a printer) of how to scale those pixels. If you keep your texture at 3000 x 1915 and merely change the DPI from 72 dpi to 300 dpi to 1200 dpi to 2 dpi all it won't change the texture - just the way it prints or displays. DPI merely tells the printer "Here's the pixels. Print it so that 72 of them fit on an inch of paper." or "Here's the pixels. Print it so that 300 of them fit into an inch of paper." Obviously the more pixels that the printer can fit into an inch of paper, the finer the detail of the print. However, computer monitors work a bit different than paper.

DPI stands for dots per inch. I could be wrong, but as I understand it, dpi is only relevant to printing. When you print a picture on paper, the printer checks the dpi setting to see how big the picture should be. A 720 pixel wide picture with a dpi setting of 72 would be printed accross 10 inches of paper for example. The setting has absolutely no effect on how big the picture will look on your screen or how much memory it will use, since both of those things depend on pixels and your picture is still 720 pixels wide. Changing the pixel dimensions of you picture is the only thing that will change how much memory is used. The quality setting will affect the hard drive footprint of the image (and the image's visual quality) but not how much memory Poser uses because, as anxcon says, Poser has to uncompress it (basically turn it into a bitmap) anyhow. I don't know whether it's really true or just a Poser urban myth, but it's said that Poser still uses the system used by a lot of older 3D apps, where textures can only be in power of 2 dimensions (256, 512, 1024, 2048 etc) so any texture between those dimensions gets treated as though it were the next size up - eg. a 257 by 10 texture would be treated as 512 by 512 because that's the smallest power of 2 square that can accomodate it. If that's true, then you'll always get the most bang for your buck by making sure the longest side of your picture is a power of 2.

Here's my take. Of coarse the textures are distributed at high res like that for close and far renders alike. You can get right up on her eyeball and the skin around it will look sharp and clear. Now if you plan to do renders, much smaller than that all of the time, and you notice your computer going much faster with smaller textures then by all means do it. Open up a 2d Program. Open the Textures and Bump maps and reduce the image size by half or even more than half. If it's at 3000x1500 for the face, you could go 1500x1250 or even 1000px on the width. Try the save for web if you have it and keep it high, 80% or higher. Compression of jpeg helps but it uncompresses when it's used so your pixels will make the most difference. Keep your zip handy or make 2 folders for textures. Go into your runtime/textures folder and just rename your lo texture folder the same name and the hi-res folder, you could delete and re-install it later or just rename it for now. All the pathways in the mat files will still point to the lo res files of the same name. And you really won't notice a difference in render quality. I guarantee it.

Okay, when I get to it later, here is what I'm going to do. I'll take the Gizelle head texture and scale it down from 3000x1915 to 1024x654 and save it as a jpg 100%. I'll do the same sort of thing with the bump map. Then, I'll render two identical closeups that are revealing of the texture and post them back here. I've long suspected Poser to be power-of-two driven, that's why my shadow maps are always multiples of. ::::: Opera :::::

If you really want to test the power-of-two memory management, run a monitor utility while rendering a test scene with maps of, say, 512, 600, 900, and 1024 consecutively. As for reduction; I have a couple of texture sets I love but they are huge. So I've also got clearly-labeled 50% reduction in pixel size (resaved as JPEG at 100% -- practically no compression) and even a new MAT pose or two to go with them.

Yes, they should look identical if you do it. As long as you keep your render size relevant to the texture size.

about the power of 2 thing, P6 might have it different the texture size setting in render settings isnt power of 2 but again, might mean nothing at all, just random thought monitoring memory during some renders would show also most skin textures i've seen (especially lately) seem to just be 1 ratio of colors, as red changes, so does green and blue by same amount, to keep the ratio the same thats why i've been using greyscale maps in my work greyscale seems to render faster, and much less memory and just feed it into a colored input instead of pure white speed might be due to i saved maps as 8 bit greyscale so 1/3 the info needed, one thing i do know, texture loading is faster lol well duh but anyways

Heh. I've been thinking a lot lately about splitting textures into greyscale map, and chroma map. Seems it would be more flexible that way.

The actual size in bytes of the JPG/PNG/Whatever file on the harddrive is completely irrelevant, as Poser will always uncompress the file. So a 4096x4096 texture will always use 64 MB no matter if it takes 1kb or 64MB of harddrive space.

The only way to reduce memory usage is by reducing the actual size. A 2048x2048 texture will consume only 1/4th the memory.

Message edited on: 02/23/2006 17:31

it is, very much so, and much easier to change skin tones ESPECIALLY with eye maps, they take a bit more work though but the end result can go into a colorramp and endless reaults :)

Just a few observations.. The "powers of 2 thing": It's true. It's got nothing to do with Poser really, it's got everything to do with the the underlying operating system (certainly Windows, and IIRC, Unix). Their system calls to manipulate bitmaps (which, incidently, are probably the fastest available 'cos they're written at the lowest level to take advantage of the PC's machine language), work best with bitmaps which are in powers of 2, especially in the X dimension, and probably in the Y dimension too - I'm a little rusty on that aspect. Bmp/jpeg/tiff/png size: Whatever they are on disc, once they get into Poser they'll be decompressed (if necessary) into memory to fit the "powers of 2" thing. It's quicker that way (until, of course, you start running out of real memory and disk-swapping starts up..) DPI/PPI (Dots Per Inch/Pixels Per Inch) etc. If you're only going to render for screen, then ignore it entirely. If you're going to render for printing things get a lot more complex, and I'm not going there now (too tired). The rest of this (if there is much more, I'm thinking(?) as I type) is directed at screen pics only... Consider a bitmap, 1024x1024. For a head, say. How big will that head texture be in the final render? If it's a close-up portrait then (on a 1280x1024 image) you'll probably need all of it. Don't forget, the texture wraps around the head, so approx. 1/2 of it won't be seen. But if it's for the head on a full-figure shot (with the figure taking up most of the screen), then the head will be approx 1/6th of that size. So the rendering software will have to scrunch the texture down, anti-alias it etc. to 1/6th of its size. And lose a lot of detail in the process. Now, most 2D applications can do a better job of re-sizing down than renderers can ('cos 2d aps are designed to be able to do these things, whilst renderers have other things on their minds). So in that case, squish the bitmap in a 2D app 1st (by about a sixth). Then apply the squished bitmap in Poser. If any of the above didn't make sense, I apologise - it's just my way of looking at things and probably explained badly. But it seems to work for me.. Things are different if you're going to render for printing, but that's a whole new can of worms, for another night.. I really do hope that helps.. It's about as clear as I can make it without going into minute mathematical/programming/scientific detail (much of which I don't have anyway) as I can. If I confuse or (more likely, have got something wrong), I apologise. Cheers, Diolma (drat, took so long typing that many others answered befoe I could post. Oh, well, feel free to ignore..)

operaguy wrote: "...and save it as a jpg 100%." I don't want to nitpick, but my smart doc on JPEG says: Quote: "Except for experimental purposes, never go above about Q 95 (i.e. 95% quality); using Q 100 will produce a file two or three times as large as Q 95, but of hardly any better quality. Q 100 is a mathematical limit rather than a useful setting. If you see a file made with Q 100, it's a pretty sure sign that the maker didn't know what he/she was doing." End of quote. The above statistics show 3 saves of the same picture with the JPEG 6.0 library. As you can see, 100% quality = 1:6 compression = 658.3 KB filesize 95% quality = 1:10 compression = 364.3 KB filesize 80% quality = 1:21 compression = 187.8 KB filesize. 100% JPEG quality doesn't mean a lossless save. There is always a big difference (in quality and filesize) between a PICT or TIFF save, and a JPEG or GIF save. But there is no visible difference between a 100% and a 95% quality JPEG save. Of course, the filesize or file format don't affect the memory load when the picture is opened. Different programs use different JPEG quality scales. For example, the QuickTime JPEG library saves the same picture with 100% = 1:9 = 420.9 KB 95% = 1:9 = 406.4 KB 80% = 1:11 = 331.8 KB.

Try bitmap shrinker. freeware app. size as desired. Set sharpen to 50%.

well, the poser community is committed to lossy image maps, I am just conforming. I'd have thought that the whole community would despise lossy maps. Are you telling me that texture vendors, after going through hyper intense effort to get every pixel perfect, then save it out to jpg 80% or 95% for sale? Is that standard? ::::: Opera :::::

jpeg isn't saved just as "95%", it also has another setting (forgot that name) for the way it samples the pixels, to decide on the way to compress a file into jpeg not sure which apps have it, many lower end apps i've seen don't which mean the sampling is set only one way (most likely default) i know PSP has it, but again this is for compression and for those who don't know, setting compression to any settings creates changes, even at 100%, unless sampling is 1x1 it might not be noticable, but if the result image is being used as maps with and such, it can create noticable changes in the end, i'd never compress and lose quality for the parts used in a pic, only compress the full end result and then only if needed, and i always keep full unchanged renders just incase i want that extra bit of quality for somethin

downsizing, progressive and optimized I have those settings on my 3D jpg export page I just took the Gizelle 1332K texture and scaled it from 3000 to 1024 and made two different jpgs, one at 100% with highest settings, came out to 517K then I did 95% with lowest settings, came out to 180K I'll make some renders tonight/tomorrow. ::::: Opera ::::

Opera, from back in my programming days, I agree with Diolma about the Windows power-of-2 thing. And most graphics software for Windows takes this into account a utilizes a power-of-2 texture sizing. Adobe has their own memory management, so they may be the exception. As to texture map size, an old rule of thumb from long ago was use a map that is 1 1/2 times the rendered size. For example, if you're rendering 1280 X 1024 and your characters head occupies about 1/2 the screen height or 512 pixels, then your head map should be fine at 768 pixels in height. Regarding texture file type, a .tif with lzw compression is probably one of the smallest lossless file types. If you're gonna use jpgs, Save to Web in Photoshop uses Imageready's optimized jpger. It compresses aggressively where there's little detail and less aggressively where there's high detail. At 70% to 80% compression, the jpg is virtually indistinguishable from the original. Just my two cents, your mileage may vary, Mike K

"Are you telling me that texture vendors, after going through hyper intense effort to get every pixel perfect, then save it out to jpg 80% or 95% for sale? Is that standard?" It appears to be so. Some may not know about it being lossy. Some know, but there's a file size/quality tradeoff that they're willing to accept. A first generation jpeg is often hard to tell from a non-compressed image. As you save and resave it, however, it becomes more and more apparant. In Photoshop you can look at the blue channel and see artifacts near areas of high contrast. That's why If I'm working on something that I got as a JPG I save it in a non-lossy form until I've got it done. At the very end, if I need to for a specific reason, I'll save it as a JPG.

Yah. I work in tif/psd up until the final save-for-export. Then, because of file size restrictions et al, I go for somewhere around 6 or 7 on PhotoShop's scale. That translates to huge savings and not too many compression artifacts. What I meant about re-saving purchased texture maps as JPEGS after reducing them in size -- they came as JPEG and I'm lazy enough to keep them in JPEG, re-compression artifacts be damned. It just makes it easier for me to find them. And after all, the only reason I'm reducing is that 2048x2048 for eyelashes is just a waste of RAM for most of my renders. At 1024 it's still wasted RAM, but at that point it's RAM I have...

I always shrink down eye textures. Why would I need 1500x1500 eye texture ? Even for extreme close-ups it's a huge waste of memory :/

The power of two thing for texture sizes doesn't hold true nowerdays. About ten years ago it was beneficial to use powers of two because processors and therefore applications could calculate row positions faster, but modern processors really don't see a benefit and most access to images need to go through various API levels and/or use precalculated lists of row addresses. On the other hand, it may beneficial when reducing texture sizes to do so by 1/2 posers, i.e. 50%, 25% etc. reduction. Thats because most resampling/filtering calculations do give better results when they applied at actaula pixel boundaries. Bill

Attached Link: http://ftp.die.net/mirror/wtc/

I do recall reading that the 'powers of 2 thing' is/was based on the way the video hardware operates. Googling around, I also see that OpenGL uses only powers of 2 textures and supposedly has to resize anything else.

I definitely agree that the relative size the texture is going to be rendered at should determine your map size if you want to reduce.

On the whole jpeg compression issue, I'd say find out what works best with your setup.

"I'd have thought that the whole community would despise lossy maps."

I think it's mostly a matter of bandwidth. For most people, the extra quality just doesn't justify the huge file size a .tif or other lossless map would mean. That's my take anyway. The original Poser textures were in .tif format. I really wouldn't want to download AngelfishMap.tif at 2,493 KB when the .jpg version at 321 KB is going to look just the same.

Talking about hi-res imagery, OT but fascinating, an aerial image of ground zero taken on Sept 23, 2001 by NOAA's Cessna Citation Jet from 3,300 feet, using a Leica/LH systems RC30 camera. 14MB @ 9372 x 9372 so you might want to save it rather than trying to view it in your browser.

Message edited on: 02/24/2006 05:00

Message edited on: 02/24/2006 05:03

A few other thoughts on file formats and stuff. Control maps, such as a transparency map, can often have a very limited variation in colours, right down to black-and-white. There's still the problem of the uncompressed version in memory, but JPEG doesn't cope well with this sort of image. I've used both GIF and PNG, but I've hit problems with how Poser 6 reads a PNG file. For greyscales, the GIF format can store as much detail as JPEG. There's P5/6 rendering options where several samples are rendered for each image pixel, in essence a more controllable version of the Poser 4 anti-aliasing option. So it may be worth having more detail in a texturemap than the pixel-count of the final image suggests. But if you're talking about uniforms -- several people using the same texture -- there's no advantage in using a smaller copy of the texture for the more distant figures. Don't forget P5/6 Materials can replace texturemaps, if the object is sensibly grouped. Mapps has a large, free, collection available here, and the Magic Skins set in the Marketplace is something I routinely use to replace texturemaps. An irritating feature of some clothing sets is that all the items are UV-mapped to use a single texturemap, which is memory-efficient if you want to use the whole set with a particular texture scheme. But if you want to mix-and-match, or you want a good resolution on a t-shirt slogan, it gets messy. But look at the Image_Map node in P5/6. You can scale and offset an image so that it only covers a part of the total UV-space.

This is my baseline image with full face texture 3000x1519

This is with the texture reduced to 1024 width. I had to change some shader settings, because going to the reduced texture cut out a lot of detail, and the surface became "less mountainous".

There is a definite loss of detail this close in. For less extremem shots I think this strategy is worth it. While I did not see much of a gain in overall rendertime with the smaller texture, I believe that if one reduced the size of all the textures one could kick the bucket size up and not run into memory errors. Thus rendertime should benefit. Another way of looking at it: by reducing texture size, you can get more models into the scene with decent quality. ::::: Opera :::::

And... I know you're an animator. When you've got her moving, the loss of detail that you see in this still will probably be a lot less noticable. Especially if you give her expressive eyes. That's what they'll look at.

I am exploring high-detail close-up stills and portraits for another 'angle' In Poser, shots like this cost about 600 seconds, so not a candidate for animation on this level. I agree you don't need this much fussiness for animation, and about the eyes. :: og ::

Aw, c'mon and admit it... You're just driven to be a master craftsman! [grin]

...and suffering because of it! I've got a long way to go, this is a difficult craft, whether Poser or something more ambitious. textures are driving me nuts I can't find a good one for Miki This Gizelle has good detail, but trouble with nostrils and at the corner of the eye/lacrimal. :: og ::

just a thought does poser load only one copy of each map? like V3, there are a dozen zones for skin, but 2 maps even if 1 copy loads for body, it still has many nodes overall so you can combine all skin zones for the body (no head) while no benefit close up, still has a gain i bet

Of course Poser loads each texture only once. And i doubt that 1024 is a good resolution for the test with the image above. It's not enough (assuming the face is a cylinder/ball with radius 250px this would need more than 1500 px to have 1 pixel for each pixel of the circumference...) 2048 would be more appropriate.

my post above made me think why not pose, then after, split the face into 2 mat zones? faces towards the camera get 1st mat, with hires map and the "side" faces get 2nd mat zone, with lower res map or am i backwards? need sleep :x seams probably not much of a problem, uses more ram though then again might not work :x dont mind me, random things pop in my head all day -_-

O hav'nt read this whole thread, just the first half dozen replies or so... The rule of thumb is you never need a texture bigger than your final render. So, if you are rendering at 720x540 then you can reduce all your textures to 720x540. = )

The caveat to that would be best illustrated by the example of doing a close-up of someone's eyes. Whatever is in the shot would need to be 720 x 540 but a normal head is a lot bigger than just the eyes. Therefore the head texture would have to be proportionally bigger. In other words if you zoomed in and showed one third of the face in a close up, you'd probably need the head texture to be at least 1620 pixels in height. If the texture itself was a full-body texture then everything would need to be proportionally bigger.

So can is it accurate to say that the size of the portion of the texture in the render needs to at least match the render size? This is easier for me to visualize in terms of V1/2 textures which have a distinct front and back. If the face is going to be 500 pixels wide in the render (using the pose above), then the front face part of the map needs to be at least 500 pixels wide, irregradless of what the overall head map size turns out to be? Conversely, if you took the full size map and cropped it to just the face, the resulting size would be the maximum resolution facial render size?

I hope others chime in, but that is my impression. That's why I am losing detail at 1024 above, because the width of the head from temple to temple in the close up render IS around 500 pixels, but if I look at the texture map, the width of the face from temple to temple takes up about 270 pixels. Poser has to 'blow up' the texture, and we all know what a .jpg looks like blown up beyond its root resolution. ::::: Opera :::::

What about using the reducing resolution option in Poser? How much time does it take? How much time did the two examples above take? (Posts 33, 34)

Bobasaur - Good caveat, i was going to add that. lmckenzie - You started off right, but then I lost what you were aiming at toward the end, but no you ca'nt render larger than the size of the texture(Well tht's not totally true, but true enough to keep everybody on the same page and looking good.) Opera - That sounds exact.

ghost, if you mean render time, the render for the full size was 578 seconds, for the reduced set 499 seconds. I don't think direct rendertime reduction is the goal here...I think being able to fit more elements into one's scene without running out of memory, is. :: og ::

Ya'll sound like you've got it. If there isn't enough original texture to fill in the required space, Poser (or any 3D app) has to interpolate - make up it's own - to fill in the missing pixels. I doubt any software is 100% accurate with anything other than a solid color.

I was sort of wondering. Part of it was I wasn't sure if the size reduction at render time would cause a huge increase in time. I do know it allows you to render more items though.