Two identical renders vastly different file sizes. Why?
RenderPretender
Posts: 1,041
Hi -
I rendered two consecutive versions of the same scene while tweaking and perfecting. The ONLY difference between them is one minor morph (bicep) tweak on each of the character's arms in the second render. The second render is 1.39 Megs and visibly grainy, while the original is 635 KB and essentially perfect. Both of the renders are 1500 x 1200. Why is this happening? :(
Thank you!
Edit: I restarted DAZ and it seems to have corrected the issue. I'd still love to know why this is occurring. I had just rebooted the computer before it did, too.
Post edited by RenderPretender on
Comments
The grain accounts for the size difference, irregular data compresses less well than smooth data. As for the difference, most likely the render dropped to CPU at soem point (after which it will stay there until Daz Studio is reastarted) and so timed out after fewer iterations, and so less converged.
But that still doesn't really address why two identical renders are different. And my computer goes to CPU often anyway.
The larger render is bigger because of the artifacts it has and it has artifacts because after dropping to CPU, the rendering didn't get as finished as the rendering with the smaller filesize
Richard's explanation seems spot on to me. You explained that the renders were not identical. One was much more noisy than the other. The scene contents were nearly identical, but the resulting renders were not.
This is my theory. (This is essentially the same thing Richard said, just using different words.) I suspect you have your Render Settings set such that the rendering duration is time limited as well as iteration limited. The first render was completed in the GPU and so more iterations were accomplished in the allowed time, making the render less grainy. If you saved your render as a JPG image, the smoothly rendered scene compressed easily to the 635 KB size. The second render fell back to the CPU, perhaps because you didn't close the first rendered window or because the first one was so close to the GPU/CPU transition criteria. Because the CPU is much slower than the GPU, fewer iterations were accomplished in the allowed time limit. Fewer iterations did not allow the render to resolve all the way and left a lot of noise (grain) in the image. JPG compression is not very efficient when there is a lot of discrete "detail" like that noise. It tries to preserve that noise "detail" in the image. That results in a larger JPG file size, hence the 1.39 MB.
If you still have the Daz Studio log file for that rendering session you could see if this theory is correct. The log file will tell you whether the GPU or CPU was used and now many iterations were accomplished and how long it rendered for each image. Understanding how JPG compression works is left to the reader.
You don't have to restart Daz Studio to get it to render with the GPU again, you just need to change the scene to use less VRAM (eg: hide something off screen, or reduce a texture size). It used to be the case you needed to restart DS to get it back to using the GPU, but that has been fixed, I am not sure in which version that happened.
In hindsight, this all makes sense to me. What I'm puzzled by, though, is what "triggers" this intermittent behavior by the DAZ app. I wonder if it might be that another process is running on the computer, such as a virus scan or the like.
On a related topic, what is the optimal "wide" or "tall" side for a render that's destined for web presentation? I know there's broad discussion on this, but most of it seems to be centered around print. I like to use various aspects depending onm the composition, but can never decide what "largest" side (height/width) is optimal. I've been using 1500 px for the largest dimension, but wonder if 1200 might be better for web presentation.
This is great to know. Thank you! That'll be a timesaver if true.
Virus scan shouldn't matter, but certainly anything that is using the GPU (e.g. to do its own 3D rendering or for 2D image processing) could be eating some of the card's resources. If the system seems tight on resources don't run anything that might be expected to use graphics card resources - you can always ue something like GPU-Z to see which applications impact the card when they are launched.
Thanks, Richard. I found an article that seems to confirm the drop to CPU as the culprit. Despite what an earlier poster said, though, I still have to restart DAZ to correct it. I'm using the latest version, but it appears that merely removing somethng from the scene does not help. But rendering and cancelling is exactly what I have been doing as a matter of testing/workflow, so this may be the issue. I also preview render a lot.
https://www.laylo3d.com/category/cg/nvidia-iray/
Yes, I discovered this long ago when I had a GTX 1070 and frequently ran out of VRAM. I got into the habit of saving and closing the scene after changes and I still do that now even though I have a 3090 with lots of VRAM. I think that DAZ Studio is not very good at memory housekeeping and the fact that it takes so long to close the application before I can re-open to work on the scene again is an indication of this.
I absolutely agree. I'm trying to develop that habit now. It's inconvenient, but saves a lot of time and aggravation compared to fighting one's way upstream when not closing/reopening frequently.