Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Patashu: Thanks, I will take a look.
Here's the average picture of the Deja Vu TAS:
I think it's quite interesting; you can make out the taxi photo in the picture frame, but everything else is kinda blurry. It almost looks like some kind of work of art!
I like it!
Here's the full smb any%, kind of boring :(
Script works great (I don't even mind taking a snapshot or the extra split second it takes to render on the screen ;) except it's a bit slow at least on my computer.
Randil wrote:
It almost looks like some kind of work of art!
I admit, this was not an original idea at all. I saw this guy 10 years ago and have always been fascinated with his averaging pictures, and only now realized I could do the same thing :)
http://www.google.com/search?q=jason+salavon
What I usually end up doing for quick-and-dirty image generation is use ImageMagick's "text" format, which is a ridiculously verbose but very easy-to-generate format that you can then use the "convert" command to turn into something you'd actually want to look at.
ImageMagick is really a fantastic tool if you want to do any kind of automated image manipulation.
Pyrel - an open-source rewrite of the Angband roguelike game in Python.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Yeah, the script is a bit slow, but it does have 182835 additions to perform on each frame :). On my computer the game runs at about 16% speed when the script is running. The Deja Vu picture took roughly an hour to make.
I have made a v2 to script, here, with two minor tweaks:
1. The averaged picture is now displayed correctly - in the old script, as you might have noticed, the displayed picture was a bit off.
2. The scipt runs a bit faster.
Joined: 3/10/2004
Posts: 7698
Location: 🇫🇮 Finland
Randil wrote:
I'm guessing the best solution would be to directly convert the array u, containing all information about the averaged picture, into an image file, without displaying it first. However, I don't know how to do that, or if a lua script even can do something like that (if someone knows, I would be very interested).
Even if lua (as implemented in the emulators) doesn't support writing to image files directly, if it supports writing text to a file, then you can do it. The PPM format is ascii-based and really, really simple. Writing a raw pixel array to a PPM takes only 2 or 3 lines of code in almost any language. Then you can use eg. ImageMagick to convert the PPM to a PNG.
I like it!
Here's the full smb any%, kind of boring :(
This seems wrong, somehow - like you're losing colour information and not getting the full breadth of what's happened in the movie. I mean, look at the ones on the first page - they're absolutely flooded with colour and little variations, this one looks more like a gif.
If it produces an average for every frame thus far and then just tweaks the average, rather than summing up the total amount of red/green/blue for each pixel (31-32 bits per channel per pixel won't overflow even for a movie that lasts 24 hours, btw) and THEN dividing by number of frames then this is going to introduce inaccuracy.
If you already are doing that, then I guess SMB1 really is that boring, surprisingly enough.
EDIT: Try remaking it in the v2 script.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Switching to v2 shouldn't make any difference. Here's how the script works:
1. Calculate how many frames long the averaged movie is. The length is simply n := (end frame) - (start frame) + 1.
2. For each pixel i on screen, create a vector u(i)={0,0,0}. This vector will hold the RGB information for each pixel.
3. On each frame between start frame and end frame, then for each pixel i, add its RGB data to its vector u(i).
4. At the end of the movie, divide all u(i) vectors by n.
5. Draw each calculated pixel, one at a time, with transparency 255.
The reason why I think images made with my script look quite different from the SMB image on the first page is because my script does not take each pixel's transparency into consideration. This is intentional - using any transparency lower than 255 will make the emulator window shine through. I'm guessing alden's SMB picture takes transperancy into account, creating the layer effect. If this is true, then our methods of creating these are quite different. I made a SMB image with my script, and they are indeed very different.
Shouldn't you use an image buffer with 64-bit numbers for R G and B where you simply add the pixels each frame? Delay division until the very end. Then at the last frame, divide by the number of frames. These images don't look correct at all, like they're plagued by rounding errors.
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
Dwedit wrote:
Shouldn't you use an image buffer with 64-bit numbers for R G and B where you simply add the pixels each frame? Delay division until the very end. Then at the last frame, divide by the number of frames. These images don't look correct at all, like they're plagued by rounding errors.
This is exactly how the script works: The RGB values are added for each pixel on each frame (step 3). Since these are integer values, there are no (or at least shouldn't be) any rounding errors in this step. The division by n is performed only at the final frame (step 4). As I see it, this is the only step where there could be a significant rounding error. The script does work as intended - for short movies (say less than 100 frames) the averaged image usually looks pretty nice. As I said in my previous post, the reason why some images look ugly is probably not due to rounding errors, but probably more because the script does not take transparency into consideration.
If you felt like doing the extra work, you could probably get a nicer effect if you did a blend for each layer individually, then lay those over each other. Mileage may vary per system, of course.
For starters, though, it would be interesting to see one of these images using just the sprite layer.
Joined: 3/10/2004
Posts: 7698
Location: 🇫🇮 Finland
Patashu wrote:
This seems wrong, somehow - like you're losing colour information and not getting the full breadth of what's happened in the movie. I mean, look at the ones on the first page - they're absolutely flooded with colour and little variations, this one looks more like a gif.
I don't know if there's some kind of bug in the script or not, but getting rather dull results from averaging thousands of frames of a single game is not something which should be surprising.
If there's an enormous amount of color variation in a certain pixel, the average will most probably be a shade of gray. If the variation encompasses a large area of pixels, large gray areas are to be expected.
In areas of very little variation the little variation there is is expected to be completely lost. For example, assume that the movie is 1000 frames long and at some area of the screen you have mostly a static color, like the blue of a sky. For a few frames there may be something else on those specific pixels. However, since you have something like 990 frames of blue pixels on that area and 10 frames of something else, averaging them will drop those 10 frames of variation virtually completely out (iow. you might see something like a 1% deviation from the blue, which is almost indistinguishable).
Randil, could you average the frames of this movie using your script?
AzumaK wrote: I swear my 1 year old daughter's favorite TASVideo is your R4MI run :3
xxNKxx wrote: ok thanks handsome feos :D
Help improving TASVideos!
Here is an image averaging lua script (for FCEUX) I made. It's not perfect, but it works allright. Just enter start frame (startf) and end frame (endf) in the script while playing a movie. It is all frames between (and including) startf and endf that will be averaged. When the movie has reached frame endf, the emulator will be paused and the averaged image will be displayed on screen. Just make a screenshot to get the averaged image in .png-format.
Haha, this reads suspiciously like the usual "here is a level 1 WIP that beats yours by n frames" fare. :D
I think Warp is right. The earlier SMB ones I posted were of a much smaller sample size. They were generated by taking snapshots and running them through ImageMagick; I don't think there was any transparency issue...
Anyways, Donkey Kong!
Joined: 4/20/2005
Posts: 2161
Location: Norrköping, Sweden
moozooh wrote:
Randil wrote:
Here is an image averaging lua script (for FCEUX) I made. It's not perfect, but it works allright. Just enter start frame (startf) and end frame (endf) in the script while playing a movie. It is all frames between (and including) startf and endf that will be averaged. When the movie has reached frame endf, the emulator will be paused and the averaged image will be displayed on screen. Just make a screenshot to get the averaged image in .png-format.
Haha, this reads suspiciously like the usual "here is a level 1 WIP that beats yours by n frames" fare. :D
In case you haven't noticed yet, I am actually just a sophisticated bot the original Randil programmed some time ago. I automatically post the progress Randil makes using standardized forum posts! (seriously though, that post made me smile. I guess I do have that kind of fare) :).
alden: nice Donkey Kong image! I have done Shadowgate and Uninvited too:
Zeupar: I think so, give me some time and I'll see what I can do.
Tetris B-mode!
I've been trying to do something with gui.gdscreenshot()... either using transparency or directly manipulating the resulting string. But failing :( Seems like it might be faster?
Logically, the next thing to do is to fade out the image to 10% alpha, then overlay it over the original video. It's like it's a burned-in CRT or Plasma screen.
Logically, the next thing to do is to fade out the image to 10% alpha, then overlay it over the original video. It's like it's a burned-in CRT or Plasma screen.
Again, this will look like crap in FCEUX, but fine in any other emulator.
Again, this will look like crap in FCEUX, but fine in any other emulator.
Ah, is that what you were getting on about... I was really confused by your previous post :)
I tried doing the transparency relative to number-of-screenshots-so-far but couldn't wrap my head around exactly when stuff gets painted on screen so it never seemed to work right...
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
Not really: I just disabled the background layers so the screenshots looked like this: 942q.png
Then I did this to create the first image:
convert *.png -transparent black -average output.png
And this for the second one:
convert *.png -transparent black -flatten output.png
You're just fucking stupid, everyone hates you, sorry to tell you the truth. no one likes you, you're someone pretentious and TASes only to be on speed game, but don't have any hope, you won't get there.
I think it's quite interesting; you can make out the taxi photo in the picture frame, but everything else is kinda blurry. It almost looks like some kind of work of art!
Script works great (I don't even mind taking a snapshot or the extra split second it takes to render on the screen ;) except it's a bit slow at least on my computer.
Zeupar: I think so, give me some time and I'll see what I can do.
Tetris B-mode!
I've been trying to do something with gui.gdscreenshot()... either using transparency or directly manipulating the resulting string. But failing :( Seems like it might be faster?
