|
|
QC and very large images Any suggestions for keeping QC efficient when working with large images? I've got a little side-project (asteroid hunting of all things!) that involves processing a big bunch of large (as in DSLR size) images in 32bit mode. I've worked out the memory requirements for this at around 128mb per image.. ouch. Well, QC seems to handle tiling the images transparently in the background, and with only one image plus a few copies loaded at any one time, it should run a little slow but otherwise OK right? Well, no.. in fact when I ran my composition it ate 6GB of ram. 6GB! I only have 4GB in total, my poor mac was nearly killed :D The composition isn't that heavy though, it should use a couple of GB or so. First question then: how the hell do I keep memory usage to a minimum? One possible issue is that I'm doing feedback rendering. Using CI with feedback is well known for causing a memory leak (I REALLY fear the results of that leak in this case :D) but I've re-worked my feedback using GLSL to get around it. I don't see any leakage with smaller images, and this seems to be stable once it's used a big chunk of memory. Another problem is that the GPU's maximum texture size seems to be 1k x 1k for 32 bit mode (same memory footprint as the normal 4k x 4k in 8 bit mode). Again, QC seems to manage it seamlessly in the background, but I get issues with CI filters around the tile edges if I try to sample outside the current tile... any fix for that? For now, I've created a macro that splits the image into 1024x1024 chunks so I can process them one at a time and recombine at the end. Not ideal, but it should get me running at least.. I'll have to add some overlap to the tiles if I can't figure out the CI issue. It's still going to eat too much memory though, so any advice is much needed :)
|
regarding the CI filter edge wonkiness -- you need to define an ROI for the sampler to let CI know how much border area it needs to include to properly resample. Unfortunately, I think this is only exposed through the Advanced Filter Settings, which guarantees a memory leak at present.
CI leak aside, how do you set the ROI in this case? The actual edges of the image aren't the problem - it's the stripes through the middle at the 1024 pixel boundaries.
hmm -- artifacts in the middle (not edges) sound like a bug -- is this similar to the filter you posted on the mailing list a few months back? (I remember some back-and-forth, and finding a few oddities in CI, but I honestly don't remember the details off the top of my head :/)
Yeah, similar-ish. Want me to put a quick demo comp together and file a bug report?
I've noticed another issue too: If I use a render-in-image beyond a certain size, anything I write into it gets trashed (i.e. I get a nice glitch image instead of what I expect). I need to investigate that a little more to be sure it's not something I'm doing though. And I'm pretty sure it's because I'm setting a render target over the maximum GPU texture size, not sure really if that should be fixed, prevented, or just logged with a warning?
If you could make a simple demo that'd be great.
Regarding render in image -- there's the GL Info patch that provides max texture size, so you can already prevent going too large with a bit of glue. That said, I'm been noticing similar glitching when I'm above the half-way point, but under full size (i.e. 4096x4096 on an 8kx8k GPU) -- this is on an ATI, perhaps you're on one too?
Actually, I think you're right - it's been a while since I've hit this wall (I'm expecting to hit it again very soon :/) but I remember having to use less than the texture limit. I vaguely remember it being more like 75% rather than 50%, but maybe you're right. I'll test it when I have time.
The big issue for me here is 32bit mode. The texture limit isn't 4k4k really, it's that amount of memory. Which works out at 1k1k for 32bit.. it's not much :( If I file a bug report, will apple send somebody round with a new video card? :)