Hello,

I just ran into this new problem. When I render to disk in high resolution, it tells me that I have to render in tiles because the image size would exceed 2 GB. This didn't happen before. Just to make sure, I tried to re-render an older image which previously worked, and UF is now also refusing to render it.

In one instance, the predicted file size was around 900 MB, the sum total of the rendered tiles was about 650 MB, but it would not render in one piece.

62c277464b943.png

I wonder if anything was changed about this check in the latest version because this behavior is certainly new to me.

Using montage (part of ImageMagick) to merge the tiles exceeds 16 GB of RAM and fails, despite the combined file sizes being less than 1 GB, so I would have to do it manually, which would be a bit annoying. smile

Any ideas how to deal with this on my end for the time being?

Best regards,
Phillip

Hello, I just ran into this new problem. When I render to disk in high resolution, it tells me that I have to render in tiles because the image size would exceed 2 GB. This didn't happen before. Just to make sure, I tried to re-render an older image which previously worked, and UF is now also refusing to render it. In one instance, the predicted file size was around 900 MB, the sum total of the rendered tiles was about 650 MB, but it would not render in one piece. ![62c277464b943.png](serve/attachment&path=62c277464b943.png) I wonder if anything was changed about this check in the latest version because this behavior is certainly new to me. Using montage (part of ImageMagick) to merge the tiles exceeds 16 GB of RAM and fails, despite the combined file sizes being less than 1 GB, so I would have to do it manually, which would be a bit annoying. :( Any ideas how to deal with this on my end for the time being? Best regards, Phillip
 
0
reply

The 2 GB probably refer to RAM consumption. As PNG is a compressed format, a file 1 GB in size is likely easily beyond 2 GB in the uncompressed format in which it is first generated in memory.

There was a thread last year in which clamas mentioned an option of ImageMagick to use the hard disk instead of RAM (perhaps referring to what is discussed here) but also proposed a supposedly faster alternative using a Python script.

In the same thread, I wrote that NetPBM was an alternative with minimal RAM requirements due to processing images line-wise. It's a bit cumbersome to use, though, as the clever processing takes place in its native format to and from which one hence needs to convert PNG files.

The 2 GB probably refer to RAM consumption. As PNG is a compressed format, a file 1 GB in size is likely easily beyond 2 GB in the uncompressed format in which it is first generated in memory. There was a thread last year in which clamas [mentioned](https://www.ultrafractal.com/forum/index.php?u=/user/profile/827) an option of ImageMagick to use the hard disk instead of RAM (perhaps referring to what is discussed [here](https://legacy.imagemagick.org/discourse-server/viewtopic.php?t=33434)) but also proposed a supposedly faster alternative using a Python script. In the same thread, I [wrote](https://www.ultrafractal.com/forum/index.php?u=/topic/713/recombining-images-that-were-split-into-tiles/1#post-2200) that NetPBM was an alternative with minimal RAM requirements due to processing images line-wise. It's a bit cumbersome to use, though, as the clever processing takes place in its native format to and from which one hence needs to convert PNG files.
 
0
reply

Yes, I know it might use more RAM than 2 GB, but the thing I noticed is that I could not render fractals in UF in one piece that I could render in one piece before (and, as a matter of fact, already have rendered). Trying it again yesterday, the issue seems to have magically disappeared, but I will keep an eye on it and post if it happens again. Sorry if this was some false alarm.

Pretty weird.

Yes, I know it might use more RAM than 2 GB, but the thing I noticed is that I could not render fractals in UF in one piece that I could render in one piece before (and, as a matter of fact, already have rendered). Trying it again yesterday, the issue seems to have magically disappeared, but I will keep an eye on it and post if it happens again. Sorry if this was some false alarm. Pretty weird.
 
0
reply

This is not a RAM issue, it's a limitation in the file export code: the total size of the written file cannot exceed 2 GB in a non-compressed format. So 32720 * 17280 * 4 = 2.2 GB (4 bytes per pixel). I am going to remove this limitation in the future for image formats that support bigger files such as PNG.

This is not a RAM issue, it's a limitation in the file export code: the total size of the written file cannot exceed 2 GB in a non-compressed format. So 32720 \* 17280 * 4 = 2.2 GB (4 bytes per pixel). I am going to remove this limitation in the future for image formats that support bigger files such as PNG.

Ultra Fractal author

edited Jul 8 at 3:52 pm
 
0
reply
66
views
3
replies
3
followers
live preview
Enter at least 10 characters.
WARNING: You mentioned %MENTIONS%, but they cannot see this message and will not be notified
Saving...
Saved
All posts under this topic will be deleted ?
Pending draft ... Click to resume editing
Discard draft