I'm in the middle of developing a mediocre animation app for SB3 (and SB4, but my current focus is SB3). The app will function a lot like Flipnote for the DSi and 3DS--I'm a big fan of Flipnote and I've always looked forward to building an app in its likeness. I'm building it mainly for my own selfish purposes, but I'll be cleaning it up with pretty GUIs and stable functionality and releasing it for others to use if they wish.
The app is mostly there, I've nailed down most of the essential functionalities (multiple layers, fast frame compression/expansion (for the ~8 mb memory constraint), decent playback frame rates, a proper undo system, etc.), and what I'm left with is connecting the pieces together to form a coherent whole.
What I haven't approached yet is a simple project export system. A system to take what was drawn and animated on the app in SmileBASIC and bring it to PC in the form of sequential frames for further editing and post-processing. Because I'll be sharing this app around (both to those who are and to those who aren't familiar with SmileBASIC), I'd like such a system that can work for everyone. That is, a method that doesn't require extra hardware, hacked systems, or hours of PetitModem symphonies.
I think that method may lie in screenshots.
I envision an export process that involves the user being prompted to screenshot a series of "QR code-like" information displayed in series on the screen. The user would grab those screenshots off their SD card, drop them into a simple executable in Windows, and the executable would process the data encoded in the screenshots and then spit out a folder of sequential, properly-labeled .pngs or something for use in other applications.
I think based on the nature of my program (pixelart-esque frames consisting of a limited color palette), this may be entirely feasible. (Actually, for an export process that anybody could quickly and easily grasp, I think this is my *only* choice.)
This is where I need your help. I would call myself a good SB programmer, but I know precisely squat about: getting pixel data from .jpegs (3DS screenshots are lossy .jpegs); writing simple, distributable executables for Windows; and creating .png files. Basically, I don't know any language other than SmileBASIC, and I think it would take me a year or more just to learn the basics of these things and get such an executable out and ready for use.
I'm offering anyone with the skills for this 100 USD (via PayPal; amount is totally negotiable) to help me build such an export tool for my program.
---
I think making this thing will take a couple of steps.
Firstly, we have to determine what kind of pixel data we can gather from the minimally-compressed .jpeg that comes out of SB3. I've heard from a few people that one bit per pixel is the likely case, and based on how .jpeg compression works I think that's accurate. (JPEG uses 8x8 matrix discrete cosine transform to whittle away redundant color information from an image and preserve the more important brightness information. If we set only white and black pixels, I think we can get a completely preserved bit stream by rounding up or down the brightness of a pixel based on its distance from 0 or 255. My few tests in SB3 seem to support this.)
If this turns out not to be the case, then we may have to use 1 bit per 2 pixels, or 1 bit per 4 pixels, etc.
Lastly, we have to determine how to format and compress (losslessly) the data to minimize the number of screenshots required. I think I have this part figured out (although I have more testing to do). From my current model, the worst-case scenario of having to transmit ~8 mb of animation data (which translates to, like, several thousand roughly drawn frames), should yield a little under a few hundred (1-bit per pixel) screenshots. (Yikes! But then again, that's several thousand frames.) The average animation (a couple hundred frames) would likely yield a few dozen or so (again, 1-bit per pixel) screenshots. Small animations should fit inside a dozen or less.
These may be liberal estimations. It all hinges on the outcome of the first step.
Sounds interesting, I definitely wouldn't mind trying to write a program to convert data to animation. What do you have so far for output data - is it just plans right now?
Hmm... I think this would make a nice contest, as opposed to choosing one... you do you.
If you just want the art you could make a special single step mode that you could use the screen grab function with. It sounds like that is something you could already do. A series of screen captures should also dump into a video editor nicely.
As for QR codes, someone had a qr code generator over on the fuzearena forums, maybe you could port that over. I don't think they had qr codes that held much data however, but it would be a huge headstart.
Hold tight. I'm working on something right now for JPEG-to-pixel. It'll be done by 10 PM Pacific. I'm also working on a nice JavaFX-based user-interface, where they can drag files to the window and have them converted (after selecting a destination folder). It's a WIP.
edit: I decided to test it out at 9 PM and ran into issues with JavaFX not being included in Java 11. I'll deal with it tomorrow.
I think I can help :)
PetitModem, while normally used for its modem capabilities, has a screenshot option that allows you to take screenshots of "data" and send them to your PC to decode via the PetitModem PC application (and then decompress it if needed). You could have your program convert the current frame to the PZG format via the LZSS library, and then copy the code PetitModem uses to encode data into your program. Then you should be set. Let me know if you need help with this.
The only downsides are that the final PNG will be 512x512 in size, so the image will need to be cropped, and that this will only work for the 3DS right now, unless we can convert the LZSS library and the decoding code.
Snail, 12me12, and others did research about color compression in an attempt to improve Amihart's program archiver, and I think they found that you could use 5-bit grayscale reliably. So, each pixel would store 5 bits instead of 1. So, about 60KB per image. Not bad.
I just thought of something.
All the compression solutions that have been proposed so far rely on compressing individual frames, using something like LZSS. But what if we used frame redundancy instead? Given two sequential frames of an animation, it's highly unlikely that all the pixels will be different. We can use this to our advantage by developing a video format that only stores the changed pixels. I saw this in a Tom Scott video a while ago and just realized its applicability.
EDIT: The first sentence may have been misleading. I realize that it's not exactly what we're doing, but the rest is nonetheless applicable.
No offense, but that seems like a horrible attempt to reinvent the wheel. In a lot of scenarios that system would use more space than a raw bitmapped image.
Going based on the fact that your code searches for like-colored (please define) areas, what would happen if I were to have black-and-white dithered (pseudo-grayscale) art where very few adjacent pixels were the same color? To describe an individual pixel in a 400 by 240 images, you'd be using 17 bits per pixel (plus the color, so 20 for a Flipnote-paletted program). With bitmaps, you'd only need 3 bits per pixel. If you stored the second coordinate's offset rather than the actual coordinate, then I guess you could increase the density a little.
My system would be something like this:
1. For the first frame of the animation, store the actual image. Nothing fancy, just a bitmap.
2. For the second frame, the first bit would be a "break-even" bit. Basically, if the uncompressed frame uses less data than the compressed version (which could occur in some instances), then the flag is set to 1.
3. Once we get to a frame that is actually compressed (flag set to 0), we analyze the next bit. If it's set to 1, it's considered a continuation of the previous frame, and uses the same color as the previous frame's pixel. Since it doesn't need to redefine the color, it omits the rest of the bits.
4. If the bit is set to 0, then the next three bits will be actual color data. Flipnote uses 6 colors, so we can store the color in 3 bits, and use a color LUT to get the actual RGB color.
5. Rinse and repeat.
It could be improved by having frame references, so a frame could reference an arbitrary frame's color data rather than just the preceding frame's. Also, we could use something like RLE for storing long sequences of repeating pixels, to avoid having to write the pixel repeat flag so much. Instead, we'd do something like "the next 20 pixels are all repeats" (saving 15 bits).
I think my system is better for a few reasons:
1. Worst case scenario (random pixels, no repeating pixels), my method uses 20% of what your method uses.
2. The efficiency of my method increases linearly with color depth.
3. Your method's efficiency decreases as the screen resolution increases (since it needs more bits to store the rectangle's coordinates).
EDIT: I just realized it's 17 bits per coordinate. In reality, each pixel would use 71 bits! So worst case scenario, my system would use 5% of what yours uses.
