Luna-Canis

So I’ve got a HUGE image that’s 18000×9000, and I can’t open it with the DevIL library. The library tries to allocate the entire image all at once, and it throws an ‘out of memory’ error. (Did you ever think you would actually NEED 64 bit architecture?) The Adobe image viewer can open and view it, so I know its a valid image. I’ve chosen the ‘png’ library to link to and implement outside the DevIL library to see if I can do a progressive load and progressive display. Hope this doesn’t take too long, but its definitely a necessary step in the evolution of the application.

Got a copy of the zlib library here, and a copy of the png library here. They were somewhat difficult to build. Found a png how-to here. The Png reader/writer seems to be full featured, so I’m certain its up to the task for doing progressive reads.

The image viewer needs:

• Display which input is being shown from the buffer node
• Display zoom level
• Init zoom level to 1

For the progressive view mode, it needs one scanline per display pixel. All panning needs to snap to the nearest scanline. A zoom calculates new scanline positions to be displayed. Have to find some logic for reusing as much data as possible when panning and zooming.

I’ve implemented the simple viewer features listed above. So there are two display modes: One that allocates the entire image at once, and one that allocates view dependent scanlines. ‘GlView::pixBuffer’ is the buffer used to hold the image, so if I focus on all methods that deal with pixBuffer, and provide equivalent functionality for the scanlines, I should be able to swap out each method. The array of scanlines will be a new object called ViewDepScan.

Got a 1.0 working. I can copy scanlines from the old pixBuffer, which also means that I have a consistent mapping from image pixels to scanline pixels.

Next is the interactivity section. We’re starting with panning, which means that panning actions will trigger recooking, and also trigger pixel copy commands. This is definitely a large chunk of work that I’ve bitten off, but I seem to be getting through it so far…

Slight change in direction. I was copying the cached data and rescaling it myself to view, which is stupid because that means I have to rescale each time I pan the view. glPixelZoom allows for nonsquare zoom factors, so I can just display the raw data and have the gl card do the resizing. Saves me a lot of headache, and simplifies the caching a LOT. Vertical panning next, then scaling and resizing.

ARGH…. ok. I realized a flaw. I’ve only been dealing with the display buffering, what I need to be looking at is the buffering in the Buffer node. That needs to be implemented first, then the display buffering mirrors that. The good news is that the Buffer node knows exactly which scanline pieces are missing, which ones to request, etc. The only missing piece is the communication of the view changes from the image display to the Buffer node.

Another flaw, since ViewDepScan needs to be able to instance all types of Tile template instances, (uchar for display and float for buffering), ViewDepScan needs to be fully templated as well. Working on that now…

The ViewDepScan is fully templated, with the Tile template. Putting in the mechanism (at the no::Node level) for requesting a view for view dependent rendering. Then we begin adding the functionality into the Buffer node.

Got the pieces working together the way they’re supposed to. The Buffer node drives the GL display instead of the other way around. I can display and pan. One part I never figured out was displaying images zoomed in. The Nuke viewer handles this, properly…

Another thing to implement is zooming the view.

The ZOOM works, can now zoom in and out. Huge step. Its odd, its a kind of discrete zoom, which has more complications than a continuous zoom. At least a continuous zoom, you can filter over your samples. With the discrete zoom, you throw away scanlines based on how far they are from the target position. Took a few tries, but its working.

Two things left: Having a magnified view (huge square pixels) and these annoying blank black lines that show up. They don’t show up every time, but certain pan and scale operations produce these black lines that aren’t marked dirty, and don’t make it up the chain for execution. Odd…

Found the cause… I keep editing the scene and changing the view while scanline requests have already gone up the chain. By the time they return, sometimes the scanline they pointed to have already changed addresses. So the scanline request is becomes obsolete. I was dealing with that by finding the closest scanline, but that’s a hack. It shoehorns scanline data from one to another. The solution is to throw away obsolete scanlines, scan when finished, and request any blank lines that remain.

That WORKED. Panning and scaling works. The zoomed pixel views are left, then its done.