Digital Art Zone

2GB of RAM gets filled up pretty fast.

I believe 4000x4000 became standard because at one time the Mac version of Poser had that maximum.  I presume that’s no longer the case.

Yeah…my quick little tif image weighed in at 45 MB…so a couple of those in a scene and it would fill up real quick.

All these elements are really interesting since I’m also developing 4096x4096 textures.
I had a slightly different technical question here, but in the same idea, concerning the weight of a file for a given number of pixels and a same format (jpg in my case).
If you have a 4096x4096 jpg image of approximately 10Mo, and you reduce its quality without changing the number of pixel, just in order to reduce the file weight (down to 2 Mo), will it help users to have fastest renders or less memory usage? Or does it depend only on the number of pixel of the image and not at all on the size in Mo of the file?

I’d assume the average user has the minimum specs for DS4.5, that way it should hopefully work on most users machines without too much difficulty

I have to admit, 4096x4096 is usually more than enough for my needs, though it is nice sometimes to get some good close-ups. Most of the textures I buy are as high resolution as possible, simply because I love having the details available should the camera be near to the character. I’d be interested to see just what a difference a ‘super’ high resolution texture would do in terms of render time and quality.

At the end of the day, it’s all about whether that extra detail is noticeable enough to make the longer render times worth the wait.

Kadix - 27 November 2012 06:24 AM

All these elements are really interesting since I’m also developing 4096x4096 textures.
I had a slightly different technical question here, but in the same idea, concerning the weight of a file for a given number of pixels and a same format (jpg in my case).
If you have a 4096x4096 jpg image of approximately 10Mo, and you reduce its quality without changing the number of pixel, just in order to reduce the file weight (down to 2 Mo), will it help users to have fastest renders or less memory usage? Or does it depend only on the number of pixel of the image and not at all on the size in Mo of the file?

I havent’ tested this, but I reckon only dimensions in pixels and maybe bit depth affect memory usage while rendering. The renderer doesn’t access the compressed data of a JPEG, it’s decompressed into a buffer just like any other image. Compressed (i.e. smaller on disk) images are better in terms of performance because they are faster to read from disk and take up less space in the operating system’s file system cache.

Edit: had to remove a nonsensical portion which was a response to something else entirely. Oops.

Kadix - 27 November 2012 06:24 AM

If you have a 4096x4096 jpg image of approximately 10Mo, and you reduce its quality without changing the number of pixel, just in order to reduce the file weight (down to 2 Mo), will it help users to have fastest renders or less memory usage? Or does it depend only on the number of pixel of the image and not at all on the size in Mo of the file?

File size really only affects disk space usage, and very marginally render start-up time as a larger file will require more I/O to read.  But that startup time is typically dwarfed by the actual render time, so the one-time start-up cost can be ignored.

When the renderer reads the image into memory, it is decompressed and stored at raw resolution and bit depth.  So it will always use the same amount of memory for a given pixel resolution and bit depth, regardless of the size of the input file.  E.g., an 8-bit RGB 4096x4096 texture will always use 49152MB of memory.

cwichura - 27 November 2012 10:32 AM

Kadix - 27 November 2012 06:24 AM

If you have a 4096x4096 jpg image of approximately 10Mo, and you reduce its quality without changing the number of pixel, just in order to reduce the file weight (down to 2 Mo), will it help users to have fastest renders or less memory usage? Or does it depend only on the number of pixel of the image and not at all on the size in Mo of the file?

File size really only affects disk space usage, and very marginally render start-up time as a larger file will require more I/O to read.  But that startup time is typically dwarfed by the actual render time, so the one-time start-up cost can be ignored.

When the renderer reads the image into memory, it is decompressed and stored at raw resolution and bit depth.  So it will always use the same amount of memory for a given pixel resolution and bit depth, regardless of the size of the input file.  E.g., an 8-bit RGB 4096x4096 texture will always use 49152MB of memory.

While that is true of the renderer, DS itself will use the compressed image for display purposes…so in reality you will have any given image loaded into memory twice, when you start to render (along with it being written to a disk cache/temp file).

Wow, wow, wow!
Thank you so much everybody!!!
I did really not expect to have so many clear and technical answers!

I’m really happy with all I read here, total pixel result in RAM, but file size well… results mainly in file size on disk!
Thank to all of you, I got my last day busy remaking all my textures with full resolution jpg now, allowing to keep all the small close up details I was so sad to lose before.
Thanks again, and may you have a great and happy day!