ALICE Progress

[PyTom]

So, actually spent some time hacking on alice. I just checked the 490 lines of python (physical, including blanks and comments) I wrote today into the subversion revision control system, so I've officially passed through the "just playing around" phase of development, and into the writing it phase of things.

Today I wrote the main window, which is the window that lets the user pick which layers are included in various configurations. Here's a screenshot of what I have so far:



(This is a linux screenshot, things will look different on windows.)

So far I'm automatically generating thumbnails from the image files on the disk, automatically generating a data structure to represent layers and images, letting the user create, rename, and delete configurations, and letting the user pick which layers are in which configurations. The File menu isn't hooked up yet, so all changes are currently transient.

Right now, there's no rendering at all, as the rendering engine is something that needs to be written. I'll probably do loading and saving first, just to make testing easier. I don't know when I'll get to rendering, but what I have here will make it into the final program.

[ShiraiJunichi]

Alright, things are looking well. Keep up the good work!

[saru]

good job!

/me wait final program. ^ ^

[PyTom]

Day 2:

Implemented loading and saving, and the rest of the file menu. Took longer than I thought, because for everything you do there's some sort of dialog that can come up asking you how you want to do it, or if you want to do it at all. (That's not to say that you'll encounter there dialogs very often... but they have to be there, and that means I had to code them.)

Did some experiments to prepare for the renderer, so I now have at least some idea of how it will work, and how I can get the data out of it and onto the screen. I'll probably use PIL (Python Imaging Library) for the renderer, and push it into GTK as late as possible.

One issue will be memory consumption and performance. Right now, the Alice01 images are 1500 x 4000... which is a bit big. Storing it in memory, uncompressed takes 1500 * 4000 * 4 bytes, or 24 megs of ram.

Per image.

As I think it's not unreasonable that a configuration could comprise more than 10 images, I think that we're going to have to do something about that memory consumption. (Such big images also take a second or so to load.)

So what do people think is a decent size for the source images to be, realizing that we can't gain resolution that's not there.

[rioka]

Well, the main issue with the image size is that folks wanted the flexibility to either do a close-up of just the face, ability to use the full body, or do the standard knee/waist up pose. (Not to mention the fact to allow room for tall hats, big hair, or high-heeled shoes...)

If you want, you can reduce the height to 1500. From what I've found, it's about the perfect size for a 800x600, waist up image, plus you can always increase the size for an up-close face shot without sacrificing the quality of the image that much. See below for example. At this size, you can significantly reduce the file sizes of all the parts. One file I tested it out on reduced from 316KB to 92KB just because of the file reduction from a 4000 height to a 1500 height.

Well, it'll be up to the users to determine what they want... =)

[monele]

Not saying about filesize but when it comes to memory, I think you could process source pictures into their desired format (face close up, full...), resize accordingly, and only keep the small displayed version (wouldn't be larger than 800x600 according to most games resolutions right ?).
Then if the user changes between full body/face close up, you reprocess the pictures.

[PyTom]

The problem, though, is that I want to keep ALICE at least vaguely interactive. And simply loading a 1500x4000 image into memory takes a second or so on my machine... which is a fairly long wait, and one I'd like to avoid if possible, especially multiple times.

[monele]

What else can be done ? Keeping multiple versions of the pictures on the hard disk then? :/. Maybe it's better on the speed side, but when it comes to downloading it... ^^; not so good.

[ShiraiJunichi]

Maybe you could use smaller pictures while working in the program, and then when you export, perform all of the operations on the original sized images