1 2 3 4 5 6 7
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
Yeah it'd take a while... EDIT: oops, should read the thread first before commenting ^^'
Joined: 2/26/2007
Posts: 1365
Location: Minnesota
I like the Paper Mario.
adelikat wrote:
I very much agree with this post.
Bobmario511 wrote:
Forget party hats, Christmas tree hats all the way man.
Player (121)
Joined: 2/11/2007
Posts: 1522
Nice! I should really dig up the lua scripts I wrote and post them. But I probably won't! Cause that's just the kind of guy I am this week.
I make a comic with no image files and you should read it. While there is a lower class, I am in it, and while there is a criminal element I am of it, and while there is a soul in prison, I am not free. -Eugene Debs
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
alden wrote:
Nice! I should really dig up the lua scripts I wrote and post them. But I probably won't! Cause that's just the kind of guy I am this week.
Sure, when alden says it, it's funny. But when Flygon says it? Oh no! Either way, I'm a fan of this project, feel the need to share that.
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Some more that turned out good:
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
The below is what happens when your image just isn't right. Source Output I'd make an AviSynth script for this if I understood at all how its indexing system worked. Of course, it's notable that my method is definitely different to Randil's, and certainly worse.
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
To be fair, I have so far posted images that turned out good - my program has a tendency to choose gray instead of more colorful colors. For example this image: turned out like this: I think the problem lies in the distance function. I'm using the same one I used for the mosaic script I made, namely this: If the pixel you are to choose a color for has RGB values R1, G1 and B1, and color i (i is 1,...,15 since Mario Paint has 15 colors) has RGB values R(i), G(i), B(i), then the distance function is defined as d=|R1-R(i)|^p + |G1-G(i)|^p + |B1-B(i)|^p Here the RBG values are between 0 and 255. The script loops through all 15 colors and picks the one that gives the smallest d. p is a parameter you can change in the script. I used p=1 in the pictures I posted. I seem to remember Derakon mentioning in the Mosaic thread that you should weight the RGB values differently. I might need to do this. Another option would be to choose an entirely different distance function. Any thoughts on this matter?
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Derakon wrote:
Neat! Now add dithering. :)
You should ask Bisqwit about that. He's the dithering guru.
Joined: 11/4/2007
Posts: 1772
Location: Australia, Victoria
We have the same greyscale issue, it appears. I've figured out a way to convert video files using only the palette, but I would really rather use the algorithm that Randil has got going on here. A configurable AviSynth plugin would be unlikely, but wonderful. :p If anyone wants, I can produce a GIF/YouTube video, but I can't promise it'd be too pretty.
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Flygon wrote:
[...] but I would really rather use the algorithm that Randil has got going on here.
Here's the matlab-code, well commented. You should probably be able to read it even if you don't know matlab well: http://pastebin.com/A1RVMTqD This is the "mainpic" mentioned in the code: Good luck!
Active player (356)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Randil wrote:
I think the problem lies in the distance function. I'm using the same one I used for the mosaic script I made, namely this: If the pixel you are to choose a color for has RGB values R1, G1 and B1, and color i (i is 1,...,15 since Mario Paint has 15 colors) has RGB values R(i), G(i), B(i), then the distance function is defined as d=|R1-R(i)|^p + |G1-G(i)|^p + |B1-B(i)|^p Here the RBG values are between 0 and 255. The script loops through all 15 colors and picks the one that gives the smallest d. p is a parameter you can change in the script. I used p=1 in the pictures I posted. I seem to remember Derakon mentioning in the Mosaic thread that you should weight the RGB values differently. I might need to do this. Another option would be to choose an entirely different distance function. Any thoughts on this matter?
Try a distance function in Lab color space (designed to be perceptually uniform) http://en.wikipedia.org/wiki/Lab_color_space
TASes: [URL=http://tasvideos.org/Movies-298up-Obs.html]Mr. Nutz (SNES), Young Merlin 100% (SNES), Animaniacs 100% (SNES)[/URL]
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
I tried using the euclidian distance in the Lab color space, but the image got even greyer: I double checked that the program works correctly, and it seems like it does. Strange...
Active player (356)
Joined: 1/16/2008
Posts: 358
Location: The Netherlands
Might be that the lightness (L) component is domating your distances? iirc L does not have the same range as a* and b*. Perhaps rescaling them to the same size improves the result edit: Unfortunately didn't bring my work's laptop (which has MATLAB) :/ edit2: To test the script, run it on a 'full' color map: http://javascript.internet.com/img/slider/hs.jpg
TASes: [URL=http://tasvideos.org/Movies-298up-Obs.html]Mr. Nutz (SNES), Young Merlin 100% (SNES), Animaniacs 100% (SNES)[/URL]
creaothceann
He/Him
Editor
Joined: 4/7/2005
Posts: 1874
Location: Germany
At least you can draw it quickly with the FloodFill tool.
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Interesting, there are some noticable differences between the Lab version and the old version. Original: Old version: Lab version: I'm not sure which one is best of those two.
Joined: 2/26/2007
Posts: 1365
Location: Minnesota
I think the old version looks more... right? Wrong word, but whatever. The colors seems to change/fade at an even pace, whereas Labview has less smooth transitions.
adelikat wrote:
I very much agree with this post.
Bobmario511 wrote:
Forget party hats, Christmas tree hats all the way man.
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
The color quantization tests Bisqwit posted are interesting (I hadn't noticed them before). They mainly show how great a job scolorq does. Of course, it doesn't looking as impressive when it's restricted to a fixed palette such as Mario Paint's, but it's still pretty good at dithering (these are mockups using the correct palette): Not needing to dither would be better, but there are so many colors missing from the palette that you probably need to either use extensive dithering or be extremely picky about which source image to use. As for actually quickly creating images like this in-game... I would guess that the fastest way is to use the "draw sprite" tool to draw 16x16 blocks of solid color (or the eraser for the almost-white background color), then switch to smaller tools like the 2x2 pen and (if necessary) custom stamps or carefully-planned spray-paint for the detail work. Actually, custom stamps aren't that slow to create so they might help a lot. I would avoid the paint fill tool since it seems to be very slow, although maybe it's still the best way in certain cases. And the fastest way to fill the entire image with a solid color seems to be the "new page" button, but unless the vast majority of the image is a single color, it's probably faster to go straight to 16x16 blocks at the start. Also, here's an idea... you could greatly increase the number of colors that appear to be in the palette for any 120x80 block of pixels in the image, by using the animation tool at speed 13 to create a 60hz flicker effect to simulate having colors halfway in-between any two colors in the palette. Compare the region with Mario's face in this image with the first one above:
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
I made another approach where I divided the picture into 2x2 blocks and looked for the best combinations of 2 colors (one color in the NW and SE corner, another in the other two corners) for each of these blocks. This took care of the grey-scale issue, but the resolution isn't very good now: EDIT: Some more images with this approach: As you can see, it still has some trouble with smooth transitions, but I think it looks better now. EDIT2: One more to show the differences - First one is the one made with my first script, then comes the 2x2 version, and lastly the original: Flygon's picture made with the 2x2 script:
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
I made another approach where I divided the picture into 2x2 blocks and looked for the best combinations of 2 colors (one color in the NW and SE corner, another in the other two corners) for each of these blocks. This took care of the grey-scale issue, but the resolution isn't very good now
This probably also makes it much easier to draw in-game. But maybe a hybrid approach would work better (where it looks for a match with either a solid color or a pattern, whichever is closer on average)? Or maybe this is simply approaching regular dithering. I think these images aren't the best sort of thing to try putting in Mario Paint, but for some comparison with ones you posted, here they are with scolorq dithering:
Skilled player (1827)
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Your pictures clearly look a lot better than mine, in particular the color scale image. All colors look more correct too. Perhaps dithering is the way to go. I don't know how much time it takes to apply the scolorq filter, but my 2x2 filter takes 1-2 minutes per image (although the code isn't optimized, so maybe I can get it shorter).
Emulator Coder, Skilled player (1310)
Joined: 12/21/2004
Posts: 2687
Randil wrote:
I don't know how much time it takes to apply the scolorq filter
It varies, but scolorq took 11 seconds on the color scale image on my system. I think scolorq can be optimized more as well (it seems to spend about 20% of its time on allocating and deallocating memory on the heap in inner loops, and about another 60% of its time on simply inserting elements into STL vectors, which is a lot of time to be spending on the bookkeeping instead of the actual computation). I put the version of scolorq I'm using here. It's based on the Windows source for scolorq 0.4, and has been modified so that I can use "m" to specify the Mario Paint palette and so that I can use .bmp files as input and output instead of only .raw RGB. I run it with a command line like "scolorq orig.bmp m out.bmp 0.9 3". The source image must be already scaled to the correct dimensions (248x168). Also, "m2" can be used instead of "m" to add the extra colors that can be simulated with 60hz flickering (it will take much longer and should be run on a 120x80 pixel image). The algorithm has some randomized elements and the dithering amount can be tuned somewhat on the commandline so you're unlikely to get exactly the same output images as I did.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
nitsuja wrote:
It varies, but scolorq took 11 seconds on the color scale image on my system. I think scolorq can be optimized more as well (it seems to spend about 20% of its time on allocating and deallocating memory on the heap in inner loops, and about another 60% of its time on simply inserting elements into STL vectors, which is a lot of time to be spending on the bookkeeping instead of the actual computation).
Memory allocation can indeed be quite a heavy operation in C/C++, and a program that does so in a critical inner loop is not very well optimized (unless the algorithm absolutely cannot be implemented otherwise which, while rare, is not completely unheard of; although even if this were the case, you could use a fast pool allocator). If the memory allocations cannot be optimized, then this might be a case where implementing the program in Java might result in a faster program (because Java has a much faster memory allocation).
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
I've been secretly working on a Mario Paint drawing TAS this year. My TAS uses the mouse instead of the keypad for maximum performance, but it is still rather lacking in, well, performance. The mouse ends up being rather unpredictable. So instead of drawing one pixel per frame, it takes many more frames per pixel, lifting and depressing the pen individually each time. The TAS is entirely generated with a Lua script, which in turn is generated with a PHP script, by reading from a plan generated by a C++ program, which in turn reads images generated with Animmerger. The script has understanding about the painting program's tools, and can use different types of pens, and it can use the colour patterns that include pre-defined dithering masks. It also knows about the bucket fill tool, but it only uses it in the beginning of the render of each image at most. The set of images it attempts to render is like this: In sequence: Naruto; a car; Megaman; a manga drawing; Mario paint cover crisp and neat; Mario paint cover with more accurate colors. Once it finishes an image, it immediately starts painting the next one over the previous one. Here's my latest WIP. I don't remember what it exactly contains. IIRC the script got stuck somewhere. http://dev.w3.fi/%7Ebisqwit/mariopaint-wip-unknown.smv Oh, and about dithering: All these images are converted with Animmerger using Yliluoma-2 dithering at matrix size 16x16 with maximum 4 color combinations per pixel, maximum precombined colors, assumed gamma 2.0. The original was resized with lanczos filtering and sharpened minimally prior conversion. The dithering was rigged to produce patterns aligned to Mario Paint's brushes where possible.
Banned User
Joined: 3/10/2004
Posts: 7698
Location: Finland
Bisqwit wrote:
I've been secretly working on a Mario Paint drawing TAS this year.
Why use ordered dithering when scolorq or even Floyd–Steinberg would create a visually much better result?
Editor, Active player (297)
Joined: 3/8/2004
Posts: 7469
Location: Arzareth
Warp wrote:
Why use ordered dithering when scolorq or even Floyd–Steinberg would create a visually much better result?
In order to give Mario Paint's predefined dithering brush patterns a chance. Also, I like the ordered-dithered appearance. Also, Scolorq cannot do predefined palettes.
1 2 3 4 5 6 7