File talk:Pi-unrolled.gif

Versions

See also Image talk:Pi-unrolled.gif/Gallery Warning: This page will not just load slowly; it may slow down your whole machine while it's open in your browser.

1 -- never uploaded; stunk.
2 -- optimized; this didn't seem to work
3 -- re-uploaded as Image:Pi-unrolled-old3.gif; see which
4 -- changed in response to complaints; nominated for FP; re-uploaded as Image:Pi-unrolled-old4.gif; see which
5 -- overhauled in response to workshop; nominated for FP; re-uploaded as Image:Pi-unrolled-old5.gif; see which
6 -- 200% oversize uploaded as Image:Pi-unrolled-720.gif in response to demands for anti-aliasing; current version

Last version docs

5th revision of this work by my hand; there will not be another

45 frames

diamond marks inserted by find-and-replace graphics -- score another one for Freehand

major changes: baseline dropped 18px, no transition frames from measuring to rolling, distinguished spoke, pi symbol appears at frame 2021, no frames follow rollout

bounds layer (contrary to usual practice) contains visible background; ON for all frames

summary frames:

1080, ON for all subsequent frames
200x, ON for all subsequent frames
207x and 207y, ON for all frames 2021 to 2100 inclusive

target frame size 360 x 114 px

for some reason Photoshop rasterizes into oversize windows:

0999, 1000, 1005, 115 px wide
1010 to 2074 and 2100, 116 px wide

in both cases, extra px appear at LEFT edge

2075 to 2080, wheel rollout forces oversize at RIGHT edge but fortunately, there is still 2 px extra at LEFT edge -- two crop operations required

for all frames, 116 px tall; extras appear at TOP edge

pi = 226.15 px

360 / 114 = 3.158 (put that in your pipe and smoke it)

color issues:

color palette badly controlled in Freehand (operator error); pi = slate gray, baseline and measure circle quiet = black

color palette loaded in Photoshop forcing first 16 values not to include black but resultant GIFs hit the upper end of a full 8-bit palette to set black; must be reduced in GraphicConverter

custom Photoshop palette created in GKON; paper/bounds color also tweaked

no antialiasing OF COURSE

font for pi = Futura Bold (common to several fonts)

Docs gallery:

Old discussion

see Pi-unrolled.gif/marv

New discussion

Well, I've done it: nominated the new version at FP. Let's make it a good one. John Reid 02:34, 6 October 2006 (UTC)[reply]

Anti-aliasing

Copied from Wikipedia:Featured picture candidates/pi-unrolled

Antialiasing is essentially clever blurring of an image. This is not always wise when presenting a geometric design; it leads to inaccuracy. Antialiasing does not really improve the (generally poor) resolution of your monitor; it just fools your eye into seeing more than there is.

Images are always tradeoffs between quality and file size. The latter concern is aggravated by animations, which contain much more information than the equivalently sized static image; this animation contains 45 distinct frames.

JPEG photos are handled well by MediaWiki but not animated GIFs. This format depends for small file size on a palette of indexed colors; this particular animation economizes still further by sharing one palette across all frames. The palette is very small: only 8 colors are used, therefore 3 bits are sufficient to specify any pixel. Antialiasing works by blurring the image which creates a range of "in-between" colors. This greatly bloats the color palette. Thus, a fully anti-aliased version might in theory be double in file size. In practice, the penalty is about +50%. This version is already 64 Kb. (John Reid)

Comment. Antialiasing is not blurring: both antialiasing and the unantialiased rasterization you are using are methods for going from some idealized high resolution image to a low resolution pixelization, but antialiasing is a more accurate reflection of the original image, and not the same as blurring an unantialiased image. I still think your unantialiased text is ugly, though I don't care so much about the division lines etc. But I have no strong opinion on whether the improved appearance of antialiasing is worth the file size blowup. —David Eppstein 04:50, 6 October 2006 (UTC)[reply]

Well, the file size penalty is what stopped me. John Reid 06:12, 6 October 2006 (UTC)[reply]

File size is not that big of a deal. Just anti-alias the whole thing, post both versions, and let the community choose whether the size drawback outweighs a better product or not. NauticaShades^(talk) 07:08, 6 October 2006 (UTC)[reply]

About the additional colors for anti-aliasing, they wouldn't bring a big difference in file size at all. Compare with my currently FPC on Villarceau circles, which is a full 3D render with lots of shades. It uses a whole color pallete for EACH of the 39 frames, and the full-sized file is only 582 kB in size, and it has 4.2 times more pixels per frame than this one does. That means that, with this resolution and a much simpler and constant color pallete, the file size wouldn't go much beyond 100 kB, and I dare to guess it would stay at the 90 kB mark. I do think anti-aliasing is a must-have here because of clarity and smooth-ness of shapes, and as I just explained, file size would hardly be an issue.

This is a pleasing, useful graphic that does a good job of making its point. John Reid has indicated repeatedly that this is his final version of the image, and he has gone out of his way to respond to constructive criticisms. As this is a community, I respectfully suggest that another Wikipedian do the anti-aliasing if it is truly a concern. -- Alarob 14:35, 6 October 2006 (UTC)[reply]

If another Wikipedian wanted to do the anti-aliasing, they'd need to either redraw it or use whatever vector sources John is using to make this raster image. You can't antialias an already-rasterized image to the same resolution. —David Eppstein 17:33, 6 October 2006 (UTC)[reply]

I'm happy to make the entire workfile package available to anybody who wants to build a derivative work on it. On this page you see notes that should be sufficient to duplicate my timing. You also need to get a handle on the cropping issue; it's pretty messy, not suitable for batch processing. You also need to deal with the issue of anti-aliasing blurring sharp, 1px-wide lines. You might touch up each affected frame by hand in Photoshop or you could go back to the FreeHand source and jog the lines around and see if you can get them to fall within pixel boundaries. Finally, if you're going to do it all over again, I'd suggest you might like to do the whole thing at an oversize and really show off the detail and nice-looking "smoothness". Any questions, don't hesitate to ask. John Reid 04:27, 7 October 2006 (UTC)[reply]

Anti-aliased version

John Reid 11:29, 7 October 2006 (UTC)[reply]

Question was raised at FP if the big one could be displayed in articlespace. Well, that's the issue with quality; it's expensive. I've got two big, high-res monitors and (mostly) reliable broadband; I'd be happy to see the big one itself illustrating π. I think it's more likely that the watchers of that page will prefer something in the 360px range. Not only does the thumb take up less screen real estate, readers actually download a different file, created and cached by the engine. They never see the big one itself unless they click through to the image description page; even then, only if they've not set a smaller size in Preferences (Limit images on image description pages to...).

Well, I still prefer the un-anti-aliased version; to my eye it looks better. Also, think of the starving children in Africa, staring through smeared Lexan at a kiosk set in the wall of a rusty galvanized steel shack, waiting for the page to come in on a 14.4 baud modem. But I grease the squeaky wheel.... John Reid 19:46, 7 October 2006 (UTC)[reply]

I have spent the past few minutes assessing the image, under the influence of tetrahydrocannabinol. I am admittedly not a child from Africa with a 14.4 baud modem (I am a legal major with DSL and am in the UK), but I must confess my screen is smeared and I am awfully hungry at the moment. I am running GNU/Linux 2.6.somethingorother and Mozilla Firefox Deer Park (in case this is important, although in assessing animated gifs I doubt it). I think the image is great, only I would recommend a fraction of a section more `pause' at the point where the wheel has completed its revolution and the value of pi is displayed...It pauses well at the beginning where one can clearly see the blue arrow on the spoke, but a dramatic pause (and possibly a `blink' or two) at the end of its journey (before rolling off the screen) will not only provide a clear indication of what the graphic is displaying (i.e. he viewer will see that the blue arrow which coïncided with the `0' value on the x-axis now coïncides with the 3.14bla value of pi) but also halt so that the mind can adjust to what one has just seen, the value of the graphic will increase by a few notches. It most certainly merits its current `exalted' status, but I am aware that the creator has been seeking feedback, which has largely been less than 100% forthcoming, so these are my ideas. To sum up: pause for a few ticks as the wheel rolls over the `pi' mark. Use it, don't use it... --Rosenkreuz 23:26, 9 December 2006 (UTC)[reply]

Version promoted

The version eventually promoted is uploaded under the distinct pagename Image:Pi-unrolled-720.gif. At the time of this writing, this is the most recent version here, at Image:Pi-unrolled.gif. Useful older versions are re-uploaded under different filenames (see #Versions, above).

Eventually, it will be feasible to link to this image but for the time being, the nasty thumb caching bug warns against it. This seems to take about a week to clear up completely. John Reid 21:14, 15 October 2006 (UTC)[reply]