Wikipedia talk:Featured picture candidates/Translational Motion

From Wikipedia, the free encyclopedia

[edit] Thanks

EdGl: Thanks for the nomination. I appreciate it not because winning a bronze star (or something like that) is all that rewarding, but because someone took notice and appreciated it! Making that movie was actually a collaboration of my efforts and a friend across the country (who had access to a really fast Mac). I also get a kick out of how you enjoyed watching the velocity of the atoms change. This was one of a number of small details I sweated: I had actually run the kinetics program for much longer than what you see and cherry-picked the 371 frames where one of the red atoms had come to a complete halt for ten frames. One thing that nobody notices is how fast the animation loads (it's only 399 kB). I used every trick in the book to compress that file — while still maintaining quality — on this animation as well as this video featured on Phonons and Normal mode. There was originally a monster version of the "phonon" animation measuring 6,039,343 bytes and any articles that showed it loaded s-l-o-w-l-y. I compressed it to only 280 kB with very, very little difference in appearance. No one ever clamored to have the slow-loading original version put back into the articles;-) Greg L 20:12, 18 January 2007 (UTC)

P.S. I'm not sure what antilived — the guy who opposed your nomination — meant when he wrote “Aliased edges, would prefer the atoms for tracking in 5 different colours instead of all red” (my emphasis). If he meant the balls don't have anti-aliased edges and this detracts from the quality, well, that's one of the trade-offs I had to make (and what actually took extra work to avoid). I purposely used only pure red, blue, black, and white in the video so all the color content could be described using only two bits of data per pixel. Anti-aliasing the edges would have doubled or quadrupled the size of the file. This also explains why the five tracking balls are all red instead of a mix of colors: bigger file size. It's sooooo easy to do Monday-morning quarterbacking isn't it? Something else that few people notice is I added two white frames between the end and start of the loop to provide a better visual clue that the animation is starting over again. Without it, the beginning of the loop gave a disconcerting jerk in the motion. Greg L 20:38, 18 January 2007 (UTC)

anti-aliasing the edges would have doubled or quadrupled the size of the file

This is just not true, unless you save the anim uncompressed. Antialiasing creates little overhead, and with multiple Mb panoramic images a few kb to make the anim easy on the eyes would be a cheap deal. --Dschwen 14:16, 20 January 2007 (UTC)

Maybe you have different software than what I have. The GIF program I used allows black & white animations to be compressed to extremely compact sizes (just one bit of color data per pixel). The GIF program has color pallet options of 1, 2, 4, and 8 bits. The animation (featuring just four colors chosen from the two-bit pallet) allowed me to save it using the two-bit setting. I have an alternative version of the animation where the balls have anti-aliased edges and it totals 1,011,010 bytes! Additional colors requires at least double the data. Even slightly different colors inflates the file size: if I simply use a slightly darker blue for the balls (chosen from an 8-bit pallet), I again quadruple the file size. That's because even though there are only four colors, they're from a finely divided color pallet which doesn't allow for a compact file. That's apparently just the way the GIF file types work. So to pull this off, I pre-processed the raw animation in QuickTime to winnow the colors down to pure colors like pure red (255, 0, 0), pure blue (0, 0, 255) etc. before importing it into the GIF program. I don't profess to be an expert in these matters; this was my first animation. The “molecule” animation was my second. I was just trying to make a good article on thermodynamic temperature by adding some animations that spoke to the issue of motion. Getting a bunch of second-guessing from others on how I could have done a better job on the animations is just icing on the cake! ;-) Greg L 02:53, 21 January 2007 (UTC)