[BUG] Massiv waste of RAM!

[Zom-B]

Hey Ono...

I just did some tests with a mesh free scene to test my maximum resolution.
poorly such an empty scene rendered at 6000x6000 takes a Master buffer size of 411.987MB...

But at the time indigo has to display this rendered image in the output window,
it takes some extra 411.987MB just to display the image

how about displaying the saved png, and not the whole image from memory,
this should save some MB

I also found a bug, that image_save_period is linked to the display_period,
and the save period can't be smaler than the display period, so working around this issue
by setting the display_period to lets say 24 hours wouldn't save the image for 24 hours,
and possibly crashing if the extra display ram is to much for your system, because its taken before the image saves!

[zuegs]

what's about if indigo would only use a display buffer for the visible area. I mean if render is 6000x6000 but display window is only 800x600 it would be enogh to display the 800x600 part of the render image. Perhaps adding some scrollbars to the display window allows to scroll throug the rendered image (but of course will only be refreshed by nest display cycle or by a extra display/autorefresh). The question is if you can calculate the reinhard tonemapping without having to create a display buffer for the hole image?

[suvakas]

I think better solution would be to just use smaller image buffer. Like a custom size for image buffer or something like that.
The idea you are describing sounds very tricky and no go for me.

[Zom-B]

You guys thinking much to complicated!

just display the rendered png file...
its much smaller than uncompressed RAW data!

I hope I'm right that this extra RAM taken is used for output display.

best proof for this is Violet:

just open a big igi file using violet, and take a look how much RAM it takes,
compare this to the RAM the scene needed after starting rendering!

because Ono doesn't enjoyed this whole GUI coding (he somewhere wrote this),
I'm sure he used the same code for image display in indigo & violet!

[suvakas]

I hope I'm right that this extra RAM taken is used for output display.

Yep, you're right.
I'm a vray user in my daytime job and in Vray for large images we render either directly to disk without displaying the rendered image or using small preview image. So that's a common thing even for commercial renderer like Vray. Displaying large image takes RAM. Vray crashes if the image doesn't fit into memory.

[edit]
I'm also not sure if i want to see compressed image as a final output while rendering.

[zuegs]

or with a option to disable display and PNG saving, so just export the igi file, so no tonemapping is needed and also no extra memory
[edit] oups suvakas sait it already

[Zom-B]

I'm also not sure if i want to see compressed image as a final output while rendering.

png is a looseless image format.... don't worry!
the image just get clamped from HDR to 8bit:

The problem is that it seems indigo ( & violet) displays the full HDR range of colors,
but the output view should be clamped to standart 8bit,
because you can't see the extra colors!!!

[suvakas]

png is a looseless image format.... don't worry!
the image just get clamped from HDR to 8bit:

Ok. Gotcha !

[dougal2]

I'm also not sure if i want to see compressed image as a final output while rendering.

png is a looseless image format.... don't worry!
the image just get clamped from HDR to 8bit:

The problem is that it seems indigo ( & violet) displays the full HDR range of colors,
but the output view should be clamped to standart 8bit,
because you can't see the extra colors!!!

no, indigo and violet display the tonemapped images, in BITMAP format - as that is the ONLY format you can write to video memory (at least, when using the wx libraries)

Code: Select all

void ImageWindow::updateImage(const Image& image, int zoom_factor)
{
	{
	wxMutexLocker lock(wx_image_mutex);

	imageToWXImage(image, wx_image, zoom_factor);
	got_image = true;
	}

	this->SetVirtualSize(wxSize(image.getWidth()/zoom_factor, image.getHeight()/zoom_factor));

	this->Refresh();//invalidate window
}

void ImageWindow::OnPaint(wxPaintEvent& event)
{
	wxPaintDC paint_dc(this);
	DoPrepareDC(paint_dc);

	if(!got_image)
		return;

	wxBitmap bitmap;
	{
	wxMutexLocker lock(wx_image_mutex);
	bitmap = wxBitmap(wx_image, 24);
	}
	paint_dc.DrawBitmap(bitmap, 0, 0, false);
}

in this context, wx_image is of type wxImage (go look at wxwidgets.org for details), and this comes directly from the output of the tonemapping process (Image& image).

[Zom-B]

Hey dougal,

I simply have no clue about coding (besides Action Script & html), I'm just a simple Indigo user,
who sometimes think to much about stuff he doesn't really understand

I tested to load a 6000x4500 rendered png Output in mspaint,
then I opened a compressed jpg of this file both took 240MB RAM to display.
My conclusion => mspaint displays images in "RAW" pixel data!

loading the 308MB igi file into violet took 724MB RAM reducing view size to 12.5% reduced the used memory to 646MB.
12.5% of the resolution takes mspaint 5MB RAM...
So I my conclusion => "hey...loading 308MB totally uncompressed data into memory, shouldn't take 641MB of RAM"
and so I blamed the indigo & Violet code for taking all my beloved RAM away

I'm a hobbit... not knowing by learning from the book, but by observe, and this was my conclusion...

[dougal2]

yeah both Indigo and Violet probably leak memory like sieves... there isn't much explicit data removal - most is left to the OS's standard "garbage collection".

[FakeShamus]

yeah, so how hard would it be to build in a close-able display window separate from the application window? I used to render with pov-ray a lot and that was a nice option - to close or re-open the display whenever you wanted.

[dougal2]

for indigo? use -nogui
for violet? wouldn't that defeat the point?