6 ms·
True-color GIF with 32697 colors
- sitharus 13y agoThe file size isn't too bad, but in Safari the rendering time is terrible. You can see it render each block, and it takes about 10 seconds to render the whole thing. I assume this is because it's not a commonly used feature, so the code paths are only implemented for compliance rather than performance.
- deleted 13y ago[deleted]
- joshzayin 13y agoThat's just the animation -- the gif is constructed to animate displaying each block.
- fredsted 13y agoI find it very weird that the author of the page did not display this information on the page.
- deleted 13y ago[deleted]
- dfox 13y agoHe uses mechanism that is inherent in GIF specification and can be used for animation, more than 256 color images or images that do not store image data for empty areas (or any combination). GIF stores sequence of rectangular blocks of image data each with its specified position in resulting image, own palette and optional delay before start of drawing (for animation). Browsers tend to assume that GIFs with multiple blocks with zero delay between them are broken animated GIFs (and enforce some minimum delay), because such files do exist and are certainly more common than GIFs with holes or large numbers of colors.
- michaelvillar 13y agohttp://cl.ly/image/3W2V3T3N3P2i http://cl.ly/image/3W2V3T3N3P2i
- simonlc 13y agoSame thing in Firefox.
- rorrr2 13y agoSame in Chrome 26 (Win7)
- mvzink 13y agoIt may be possible to work around that: the trick they use to get full color is that each animation frame is allowed to have its own 256 color palette. So for each block of 256 colors, you have a single animation frame "played" which colors in only that block (the rest is transparent). Hypothetically, the only reason it renders so slowly is that there's a pause between playing each frame.
- Someone 13y agoYes, but it seems that delay may not be avoidable. http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser-compatibility http://nullsleep.tumblr.com/post/16524517190/animated-gif-mi... says Safari does 16 frames per second max. Drawing 32k colors at 256 colors per frame takes 128 frames. At 16 fps, those would take 8 seconds to draw.
- jamesaguilar 13y agoI think it would be cool if the gif gradually enhanced the colors, starting out with the 256 colors and filling in details in subsequent passes. The user would just notice the color fidelity increasing. The trouble is that I don't know if gif implements non-looping animation.
- tekromancr 13y agoIt does support non looping animations. The problem is that I am not sure how you would calculate the 'tween frames. I get the first frame, it's just the final image dithered to 255 colors, but what would one of the intermediate frames look like. A small box with a more restrained palate, or would you break the final image into frames based on spectrum?
- jamesaguilar 13y agoI would try to maximize the delta(PSNR) per frame, as a first cut. There are also good perceptual difference metrics. I don't know what algorithm to use. Maybe just the absolute difference on each pixel. Or, you could think of groups of colors to enhance if you're willing to grow the size of the image.
- buddydvd 13y agoIt's actually more of a hack to deal with malformed GIFs and goes directly against spec. To address GIFs where each frame has a 0 frame delay, most GIF decoders implement a minimum frame delay value. See: http://nullsleep.tumblr.com/post/16524517190/animated-gif-minimum-frame-delay-browser-compatibility http://nullsleep.tumblr.com/post/16524517190/animated-gif-mi... Edit: This is what it looks like with all frame delays set to 2 centiseconds: http://i.imgur.com/24xpZEd.gif http://i.imgur.com/24xpZEd.gif On Chrome and Firefox, you should see it animate more quickly.
- tekromancr 13y agoI figured that that was the issue. Thanks for the link!
- Wevah 13y agoGIF performance seems improved in safari, at least in 6.x, though this is just anecdotal evidence. The GIFs with 0.02 second frames (the actual ones, not just the "here's what it looks like under x browser" ones) seem to render with the same frame rate for me in Safari and Chrome now.
- sitharus 13y agoInteresting, thanks for the details
- gilgoomesh 13y ago> The file size isn't too bad 184,565 bytes for the GIF versus 34,991 for a PNG of the same or 7,692 for a JPEG with no visible artifacts. I'd say the file size is unusably huge.
- kijin 13y agoConvert it to true-color (24-bit) Windows BMP, and it's 141,538 bytes. So the GIF is even larger than the raw RGB values of each and every pixel concatenated together.
- rocky1138 13y agoPicasa Photo Viewer, when the image is downloaded then opened using this program, doesn't show anything over just the first block (top left).
- jimktrains2 13y agoSame in Chrome Version 26.0.1410.63 (Ubuntu 12.04)
- staunch 13y agoWorks in my Chrome 26.0.1410.63 (Ubuntu 13.04)
- petercooper 13y agoIt shows on the iPad in Mobile Safari but loads and fills out slowly in a grid of squares in rows and columns of 3 or 4 (I forget). It took about 15 seconds in all to render. Fascinating nonetheless and I learnt something.
- Moto7451 13y agoMobile Chrome on Android 4.0.3 has The same behavior. At first I thought it was an animated gif. Edit: looks like it is an animation of the rendering process.
- joshzayin 13y agoIt's because this is an animated gif. Presumably picasa only shows the first frame.
- jrabone 13y agoFails miserably on Chrome / Android 4.2 / Nexus 7 ...
- deleted 13y ago[deleted]
- yew 13y agoOdd. It works fine in the stock Android browser. It actually renders faster than on my desktop. Maybe Firefox has a higher per-frame delay?
- rohansingh 13y agoWorks fine for me with that exact hardware and Chrome.
- turing 13y agoThat's strange, works fine on Chrome/4.2/Nexus 4. Could you define 'fails'?
- jrabone 13y agoActually it's my proxy server that failed, didn't realise it was an animated GIF and I have it set to deanimate images by default. Ooops!
- jamesbritt 13y agohttps://news.ycombinator.com/item?id=5691086 https://news.ycombinator.com/item?id=5691086 Same URL but without the dupe-eluding # tacked on the end.
- wfunction 13y agoWhy hasn't HN fixed this?
- jamesbritt 13y agoI once posted an "Ask HN" about this and it was soon killed. At this point I have to assume it is a feature, not a bug, so it's hard to fault people who take advantage of it.
- gojomo 13y agoThe images could be compressed; the relevant patents expired a few years ago. (Is this an old page?)
- kyrias 13y agoThe last modified date on http://phil.ipal.org/tc217.gif http://phil.ipal.org/tc217.gif is 12 Dec 1999, which was 3 years before the last patent expired.
- Aardwolf 13y ago> So a GIF file with more than 256 colors gets very large very quickly. Sure, due to a library that doesn't do compression! Has anyone an example of one with compression? Also, looking at this: https://bugzilla.mozilla.org/show_bug.cgi?id=149205 https://bugzilla.mozilla.org/show_bug.cgi?id=149205 It seems that the block by block thing is not an animation on purpose, it's really how browsers render it (and other programs load only the first frame etc...), because each sub-image is a frame. So not that ideal.
- Hello71 13y agoYes. It's called libpng.
- aleksi 13y ago"32697 colors" is not True Color, it's High Color.
- mischanix 13y agoThe point is that if you render the image in blocks of 16x16, there can only be 256 colors per block, so there can be as many colors in the image as there are pixels. This 217*217 image has some duplicate pixels in the lower and higher values but gets fairly close to that maximum.
- mathias 13y agoIt’s not “true color”, but it _is_ true-color, as the title says. There’s a difference: http://en.wikipedia.org/wiki/True-color#True_color http://en.wikipedia.org/wiki/True-color#True_color
- muyuu 13y agoI lost an argument about this years ago. In Uni I learnt that you could create GIFs with more than 256 colours, but when challenged I could find none. And all references in the net mentioned just 256. I was sure but I ended up believing I just had a brainfart or was lied to in class. This is ~10 years late to my argument :(
- DanBC 13y agoI took a screenshot so interested people can see how badly images can be mangled by the proxies used by some mobile companies. (http://i.imgur.com/DYbVSbj.png http://i.imgur.com/DYbVSbj.png)
- lucisferre 13y agoWow what mobile companies do that?
- dangrossman 13y agoAT&T, Verizon, Sprint, T-Mobile... depending on network, image size, device and browser user-agent.
- Stratoscope 13y agoI just tried it on Verizon from Chrome on my ThinkPad (via mobile hotspot) and my Galaxy Note II. Both displayed a perfect image, albeit very slowly. Not saying there aren't cases where it does happen; obviously from that screenshot there are; I just didn't run into it.
- DanBC 13y agoI'm on T-Mobile in the UK. This is a T-Mobile mobile broadband dongle. They do give you the option to get the original image. They do this sub-optimally by injecting javascript into every page I visit. They hijack the alt-text, replacing it with a message that says something like "Shift R improves the quality of this image, Shift A improves the quality of all images on this page". The IP address they use for the caching / mangling proxy is 1.2.3.X (where X tends to be 9 or 11) - I'm not making that up, they actually use 1.2.3.9 which is a bad idea.
- sltkr 13y agoCool, I wrote about a similar technique (but with a somewhat different approach which I think balances file size/quality concerns better in practice): http://notes.tweakblogs.net/blog/8712/high-color-gif-images.html http://notes.tweakblogs.net/blog/8712/high-color-gif-images....
- JeremyMorgan 13y agoWhat's the point of this? Hi Res animated gifs? Color me sort of interested...
- __del__ 13y agoI can't be the only one bothered by the choice of dithering algorithm in that example, right? http://en.wikipedia.org/wiki/Dithering#Algorithms http://en.wikipedia.org/wiki/Dithering#Algorithms
- michaelpinto 13y agoThis makes me angry with Adobe: I feel cheated that for the past twenty years I could have been making GIF images with more than 256 colors in Photoshop.
- unreal37 13y agoThis is no different than 200 256-color GIFS loaded side by side. Sure, the entire image is 32K colors, but each 16x16 block is limited to 256 colors still. Plus the forced animation makes it effectively useless. What's the point of that?
- igul222 13y agoThere isn't much point, but that's perfectly fine. It's interesting just to know that it can be done, and it's a fun hack.
- 0x0 13y agoWell, in a 16x16 block you only have 16x16=256 pixels, so the blocks themselves are basically "true color". Stack blocks and you'll have lossless true color. Of course, this was more interesting before .png support became widespread in browsers. (Also, I believe you're not restricted to 16x16/256col blocks. If you can fit a pattern of 255 distinct colors + transparency over a larger image, you could stack several frames to create the same effect, without having to drop down to 16x16 local blocks)
- begurken 13y agoFrom the article: "While using more than 256 colors in GIF is in most cases a bad practice, and should be limited to certain technical cases where extreme size can be tolerated" Why would anybody do this, ever (aside from intellectual curiosity)? GIF is a dead format except for very simple small-palette logos, or simple animations. It was one of those rare formats that everyone knew sucked when it was popular, and we were just itching for it to die. Now it's (mostly) dead, the world is better, and I can't imagine why anyone would ever use it for anything that wasn't a flat-color logo.
- koyote 13y agoInternet explorer (10) doesn't even render it properly in the first place. (http://i.imgur.com/R87CGQ4.png http://i.imgur.com/R87CGQ4.png)
- fractaled 13y agoYour zoom appears to be set to 125% (not sure if that absolves IE or not -- I see similar lines in Opera when zooming). Looks okay to me at 100%.
- sageikosa 13y ago200%, 300%, 400% look fine, the in-betweens not so much. Chrome 26.0.1410.64 m loses accurate scaling once it gets big enough (400% on my system), then can't get scaled back down to 100% accurately.
- sc00ter 13y ago"No one tried or needed to generate images with more than 256 colors since they could not be viewed on anything less than high priced graphics workstations." Except that given this refers to the late 80's, Amigas had been displaying 4096 colors since the mid 80s. Not millions of colours until the early 90s but still a far cry from the 256 colours of the average PC. (No, gif was not a native datatype, but the Amiga was remarkably ahead of its time with plug-able file formats.)
- adregan 13y agoThere is something charming about 256 colors though.
- doctorpangloss 13y agoPhotoshop correctly opens and interprets this image. Frame propagation is used to achieve the effect.
- pixelcort 13y agoA couple days ago that there was another page submitted to HN describing how gif animation worked. It then suggested this technique was possible.