Wikipedia:Featured picture candidates/Duck and Cover

From Wikipedia, the free encyclopedia

Duck and Cover[edit]

Original - "Duck and Cover", a 1951 Civil Defense film about nuclear war.
Reason
"Duck and Cover" was named to the United States National Film Registry in 2004. A 1951 Civil Defense short. There's nothing quite like a singing cartoon of Bert the Turtle to convey the idea of nuclear war to children.
Articles this image appears in
Duck and Cover (film), Duck and Cover
Creator
Raymond J. Mauer and Anthony Rizzo
  • Support as conominator --DurovaCharge! 05:38, 15 August 2008 (UTC)[reply]
  • Support as conominator. This is a clearly historic piece.--Filll (talk | wpc) 18:08, 15 August 2008 (UTC)[reply]
  • Support. Sigh.. I hope the cold war isn't starting again. de Bivort 18:52, 15 August 2008 (UTC)[reply]
  • Support wow Durova, I'm all depressed now. Why can't we all just go back to the good ol' days of American history? Nice choice though. Intothewoods29 (talk) 20:18, 15 August 2008 (UTC)[reply]
  • Support Durova this is probably the strongest video ever nominated here. But as a physics major I must wonder... How effective would it be to "duck and cover" when a bomb annihilates a building. Then again the yield of nuclear bombs in the 50's was hundreds of times smaller than the thermonuclear era. victorrocha (talk) 21:10, 15 August 2008 (UTC)[reply]
    • I've seen vigorous debates over that. Apparently they based this upon the Hiroshima and Nagasaki survivor reports. Obviously all advice is useless in the immediate blast area. Beyond that, there could be a zone where covering one's eyes and skin would make a difference. The physics aren't quite my thing, but as a historic and cultural document this is fascinating. DurovaCharge! 21:26, 15 August 2008 (UTC)[reply]
  • Support - classic film, good quality. JaakobouChalk Talk 01:26, 16 August 2008 (UTC)[reply]
  • Oppose, the cultural importance of this is clear, but, I really don't think the quality is good enough. Not only is it small but, it's somewhat grainy. gren グレン 04:18, 16 August 2008 (UTC)[reply]
    • At 15.4MB it's pretty close to the upload limit. DurovaCharge! 04:29, 16 August 2008 (UTC)[reply]
  • Neutral Though I agree with the supports above, technical quality (Yes, I know its from the 1950's, but still) is too low to allow me to support. For example, in less that the first second into the video, the sound stops for a second. Next, there's black and white specks appearing all over the film. In another example, I find technical quality low in seeing the graininess of the words in 0:53 of the film. Then there's way too much light at 7:30 in the film. I could go on, but I think you can get the idea. SpencerT♦C 21:34, 16 August 2008 (UTC)[reply]
    • black and white specks appearing all over the film, now that's a restoration challenge ;-)... --Dschwen 15:58, 18 August 2008 (UTC)[reply]
  • I just uploaded a higher bitrate version over the old one. Upload limit is 20MB, the old version just used 15.4MB, this one uses 19.8MB. --Dschwen 16:49, 19 August 2008 (UTC)[reply]
    • Ooh, thank you. :) DurovaCharge! 17:02, 19 August 2008 (UTC)[reply]
      • 20MB just isn't big enough for a decent quality 10 minute video. I suppose this will be a bandwidth (and maybe storage) issues Wikimedia will have to decide. Yet, I still don't think we should be promoting these longer lower quality videos. Is there any discussion of it the limit will be upped or what will happen as video becomes more common especially with native Theora support entering entering the Firefox 3.1 trunk. gren グレン 05:06, 21 August 2008 (UTC)[reply]
        • Yes, when the new servers go online the limit will rise. I've been talking to Brion about it. Trying to find out how much, but the change will come (relatively) soon. DurovaCharge! 06:03, 21 August 2008 (UTC)[reply]
          • If the limit is increased please remind me to just upload an even bigger version over this one. --Dschwen 14:37, 22 August 2008 (UTC)[reply]

Promoted Image:DuckandC1951.ogg --jjron (talk) 08:41, 22 August 2008 (UTC)[reply]