Luna-Canis

I’m calculating duplicate scanlines. They remain blank, and keep updating in an infinite loop.

The view update algorithm which would fix this, and ironcally, is simpler than both methods I’ve implemented so far is the following:

• Calculate new scanline positions
• Find all old scanlines which still have positions in the new view and copy them
• Fill in all blank scanlines

This works for panning and scaling, pity I didn’t come up with this sooner.

Yup, that worked. Do the zoomed view, window resizing, then we’re done. We’re fully functional with zooming and panning at all scales. Final Checklist:

• Have to handle recooking, image size changes.
• Have the Buffer correctly handle multiple inputs. This is a bit more complicated than it sounds. When tile based, the different Buffer images can always be properly filled. If they’re view dependent, they can only be filled when being viewed.
• Handle display window resizing.
• When the scanlines are initialized, one channel is shifted in ‘y’. Don’t know why….

FINISHED…. Unbelievable…. Hope not to have to go back and fix that later….

Now have to link the .png library… yuck

Part II of this effort was to link in png to the image library. Then I should be able to read/process the huge image I rendered. Hope it takes shorter than the scanline crap.

A funny thing about the png win32 library is that it requires rc.exe to do the build process. I found an old copy of that on my old computer, and it worked! But it also had a virus embedded in it, so it got quarantined by the virus software. I hopefully don’t need to build it again, but I may have to unpack MSVC 7.1, and do a full install to get the binary again. —- Got a copy of the executable from Josh Krall!!!!

I got the library to link, and I can use the libpng routines to detect a .png file. I’m re-using an older zlib library that’s included with the DevIL library. When compiling libpng, it compiled against zlib 1.2.3. The DevIL library compiled against zlib 1.2.2. They appear to be binary compatible for now, lucky me.

There is a good section on reading a file here, and here is a spec for the format.

The library doesn’t allow for arbitrary scanlines to be requested. It assumes that you’re doing a sequential request of all the scanlines. Worse, it has the option to be saved in some progressive interlaced mode. When that happens, it has to be read in multiple passes.

I’ve got an idea to create a class, given the last scanline read, to calculate how many to skip, how many to read. I imagine if we have to go backwards and get an earlier line, we could close, and reopen the png file. This is better than allocating the entire image at once, but I don’t think it would have killed them to allow to request for arbitrary scanlines like the exr library.

Did some reading, the png library will de-interlace the rows for you, you just have to call the row request the proper number of times. Also, the current row/pass info is kept in the png_struct_def, so there is a chance that I can rig it to return any scanline I request. We’ll see.

Not being able to specify arbitrary scanlines is a major pain. For now starters, I’ll allocate the entire image to get the api working. If I can get hack the image reader to return the entire image, I’ll have to come up with a way to map requested tiles to cached scanlines. Basically, a way to automate scanlines prefetching an image width’s worth of requested tiles. This would be also help the exr reader.

Its not looking good for having libpng read arbitrary scanlines. I seems that the reader ignores the png_struct, it only gets updated incrementally. The lines get read out in order no matter what. There are workarounds. We can have the reader do dummy reads, close and reopen the file when it has to go backwards. If I can get a worst-case completely random scanline order to execute in a reasonable amount of time, its a win. Generally, the reads will be in sequential order.

SUCCESS.

I can read in the 18000×9000 picture. Its really slow, especially when the png reader finishes a pass, then has to close and reopen the image and begin scanning from the first scanline. But we don’t run out of memory, and its definitely faster than the adobe png image reader, which does a downrez of the image data before displaying it. Since the image is so huge, and the view lags, I’ll implement the following wishlist:

• A transparent overlay showing the view w.r.t. the entire image.
• Done - toggled on/off with ‘o’, like Houdini and the overlay mode.
• Have all the image reset hotkeys work with view dependent modes.
• Done
• Give the user the ability to maquee the next view location instead of having to interactively zoom.
• Done.
• Give the user the ability to enter the zoom value directly.
• Done. Added an interactive parameter to the pre-existing dialog box.
• When entering new scanlines, they should be sorted to minimize the amount of rewinding required of the image file readers.
• NOT Done. I implemented it, and it makes updates take LONGER. Don’t really have the initiative to try to figure out why, but the non-sorted way is clearly superior.
• Panning should be constrained to snap to pixel sized increments in y.
• Done. The result looks a lot cleaner as well.

Almost forgot. As long as I have the png library in my head, I should implement the png file writer. Also should clean up the exr reader code. Found some bugs.

Jason had the GREAT idea to rename spa/ludini to BWAIN.

I’m keeping R&D notes on features I need to implement. But for a lot of things, I need to be able to create latex. There was this great feature I read about on Wordpress.com about being able to do math/latex on their blogs. This version of wordpress (2.0.2) doesn’t have that feature. I don’t have the freedom to upgrade to the latest version of wordpress, so I just created a new blog on their website.

I’ll done with the png implementation. Now returning to the for-loops.

Had a relatively long diversion, but it was spent on worthwhile features. PLUS, I got some work out. I got this pic fully rendered and sent to the printers. Tomorrow morning, I’ll pick up a glossy, archival 64×34″ print. Psyched.

The last thing I was working on with the for-loops was fleshing out the equality predicates ‘&&’ and ‘||’. The first implementation had the obvious bool-op-bool definitions, but that doesn’t allow for int-op-int, float-op-float, int-op-bool, etc. They have to handle int, float, double, and bool on each side, so that makes 16 combinations each for ‘&&’ and ‘||’.

I figure if I get a full implementation of for and if-then-else, that’ll be enough to tackle the Ultrafractal emulation and start some real rendering.

The for-loop is almost fully working. Its hard to come up with obscure expression cases that will break it. Another thing I completely forgot are % operators. (int,float,double) % int, float % float, double % double.

Worked through a lot of bugs with the %, && and || operators. for-loops almost done. Should do some experimenting with non-varying boolean expressions, and possibly look into implementing break/continue.