I don't know what the obsession is with trying to make things into little tiny mismashes of images like this (good luck recognizing anything from that train wreck) but I'd really prefer it to stop.
It's already made this completely unusuable (in fact, now the "image" is completely blank instead of actually being there.)
I love how things that were working perfectly before are now broken.
Actually, my run has just been upgraded to "TRA COOL. "
Duh.
Sage advice from a friend of Jim: So put your tinfoil hat back in the closet, open your eyes to the truth, and realize that the government is in fact causing austismal cancer with it's 9/11 fluoride vaccinations of your water supply.
The reason why I did this change is manyfold:
P1) It invokes less HTTP accesses, because many images are loaded from a single file.
P2) It causes faster image loading times; once a file is loaded, everything that is generated using that file, is rendered instantenously. And since multiple imageries are stored in a single file, it compresses slightly better too. This kind of practice is already commonly recommended in website design. For example, all the graphics at Youtube are generated from a single file.
P3) It was fun creating that image packing algorithm and watching how many screenshots are stored in a single file. For example, this file contains all screenshots of SMB movies, obsoleted and current alltogether.
P4) It discourages people hotlinking to images stored on my servers.
I realize there are negative consequences as well:
M1) The HTML tables required to render the image properly are rather large. I optimized them as well as I could, even going so far as to utilize the table background color to avoid image masks, but they're still quite verbose.
M2) Browser bugs may cause wrong renderings. I verified this using Firefox 3, Google Chrome, IE 7 and Opera 9.52, and it worked perfectly with all of those, so it seems fairly compatible.
M3) Bugs in the composition engine itself may cause wrong renderings. That seems to be the case with both of the screenshots that Xkeeper shows.
I realize I could discard the tilemapping algorithm and just embed all images as-is in a single file, but that would invalidate points P3 and P4 from this post. :(
I'll research the bug that causes that "TRA COOL" part to appear. It seems to be the background color optimization mentioned in M1, but I need to figure out why. The Pidgey bug had another cause and has been fixed.
Xkeeper wrote:
I love how things that were working perfectly before are now broken.
I'll research the bug that causes that "TRA COOL" part to appear. It seems to be the background color optimization mentioned in M1, but I need to figure out why.
Clearly your optimizer thinks that movie is ULTRA COOL, except that it found its U and L keys to be spotty in operation.
Xkeeper wrote:
I love how things that were working perfectly before are now broken.
Oh year, mr. subtle aggression.
:)
What can I say? Today has been an utter disaster in epic proportions. Spillover is to be expected.
For the technically inclined, here's what happens at the software level.
Each time someone accesses pages at TASVideos, the site logs the list of images rendered on that particular access.
Once in a while, a certain script is run on the server. The script analyzes the log, and figures out which images are often loaded together. It takes those images in groups of ten to fourty, and passes them to an image tiling algorithm. This algorithm attempts to create an image that contains all of details of those individual images, but does so by merging identical details, such that the same graphical detail is stored only once. Finally, it outputs a list of X and Y coordinates where each individual tile of each of the source images can be found in that composed image, "superimage". Those lists are saved in the database, along with the cached information of the original image such as the vertical and horizontal resolutions.
Finally, when the site renders images, it checks the image cache to see if there's information about the image there. If the resolutions are specified there, it adds them to the image tag (to make pages load smoother), and if there is a superimage name and the X & Y coordinate lists, it composes a HTML table which reconstructs the image using those pieces from the superimage.
I think the source images look awesome -- kind of want to print some out for my wall :P
Does it try to find common detail among different screenshots, or only within a single screenshot? I guess only when it's possible...
Cool ... any way to quantify how much is shared? It would be neat to see the ones that share the most :D
It is rather volatile data. Sure, there's a way to quantify it by looking at the database contents... Compare the image entries that use the same file, and find a pair where the largest number of matching coordinates are found.
Here's a SQL dump. http://bisqwit.iki.fi/kala/imgsizecachedump.sql.gz
Hmm...it is good that it makes it no longer populate down as the HTML loads and then contract up as the screenshots fill in, making it hard to stay near a particular movie while it's loading, but the total load time of such as SNES movie list seems* longer, as it now doesn't get to the last movie's html until much nearer the end of the total load time.
As a regular, this does not impact me greatly, as I have already perused the movie lists and go by new content as it appears.
Though not quite related, the tab-structures in wikipages here also populate and then collapse, though they've done that as long as I remember seeing them working.
*subjective statement marker
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
So how do you actually compare the tiles? I can't really follow that part on that page. Get the data for some tile and compare it to all other tiles? Or maybe something like a hash to speed up comparisons...
--
btw, it also seems to me like the algorithm can be optimized even further by reducing the white tiles as much as possible. There are probably a lot of single tiles that are never used in conjunction with another tile. There's no need for those tiles to be "near" the other tiles from that game. Same for a certain disjoint group of tiles. Like in https://files.tasvideos.org/packs/6a4ad3f.png you can clearly see that some parts of that image can be reduced. Dunno how much that will improve the filesize though.
So how do you actually compare the tiles? I can't really follow that part on that page. Get the data for some tile and compare it to all other tiles? Or maybe something like a hash to speed up comparisons...
The code converts the list of pixel values in a tile region into a string and then calculates a crc32 of that string.
Those crc32 values are used to compare tiles.
As such, it is not as versatile as e.g. motion detection algorithms in x264. It can only find identical matches from a tile-aligned grid.
btw, it also seems to me like the algorithm can be optimized even further by reducing the white tiles as much as possible. There are probably a lot of single tiles that are never used in conjunction with another tile. There's no need for those tiles to be "near" the other tiles from that game. Same for a certain disjoint group of tiles. Like in https://files.tasvideos.org/packs/6a4ad3f.png you can clearly see that some parts of that image can be reduced. Dunno how much that will improve the filesize though.
By "whites" I presume you are talking about the transparent regions.
This is somewhat intentional though. I realize I could obfuscate it further, but I wanted to keep the data associated for an individual screenshot in a group (except when multiple screenshots share same tiles). The $scramble variable controls how much scrambling happens for the individual components of each image and where they are placed.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
I see.
I guess some kind of auto-animated-gif producer for a movie is out of the question now. Because it would be kickass and seemingly easy if you can automatically take screenshots from the movie anyways. But it's very much prone to hotlinking, as well as bloating up quickly.
Here's an example of a pack where even less scrambling happens than it does in the one you linked to:
https://files.tasvideos.org/bisqwit/oldpacks/b46d711.png
Here duplicate tiles are simply removed but the overall shape of the screenshot is still the same.
Joined: 4/25/2004
Posts: 615
Location: The Netherlands
Re hotlinking animated gifs; You could create the gifs and put them behind login, only allowing logged in users to see them. That would stop hotlinking hands down.
Joined: 10/27/2004
Posts: 1977
Location: Making an escape
Small bug with this new method.
The algorithm decided to snatch my Sparkster submission, and in the process decided to mess around with the formatting. Instead of the images standing to the left of the text in the header where I want them, they're standing on top. I tried using the left command in the image tags, but that caused the images to pop out of the headers, which I thought looked tacky.
A hundred years from now, they will gaze upon my work and marvel at my skills but never know my name. And that will be good enough for me.
I don't know what the obsession is with trying to make things into little tiny mismashes of images like this (good luck recognizing anything from that train wreck) but I'd really prefer it to stop.
It's already made this completely unusuable (in fact, now the "image" is completely blank instead of actually being there.)
I love how things that were working perfectly before are now broken.
