Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
User Journal

Journal I8TheWorm's Journal: expanding GIF - I'm curious 9

I saw this post today here on Slashdot. I've been a programmer sometime, but have never had to deal with CGI, much less any graphics formatting and manipulation. So it got me curious, as usual. Is it really possible to create an image that, on your disk, takes up a few (thousand?) bytes, but in display takes up many thousands?

I found a couple of sites with some good file format information, here and here. I'm going to spend a little time perusing the documents, and see if I can mimic Mmm coffee's results.

If anyone has any experience with this, I'd love to hear about it.
This discussion has been archived. No new comments can be posted.

expanding GIF - I'm curious

Comments Filter:
  • I think what they mean is they can specify arbitrary HEIGHT and WIDTH attributes to an html IMG tag, so you can make an image that is as big as you want (it doesn't matter what size the image was, since it will get resized as neede). Not sure why you would do this however... :-)
    • It's to thwart deep linkers into images on your website, possibly causing you bandwidth strain. Your idea would be great if you could send the whole tag with it, but alas, it's no good for just the image. I was able to fake a 1px x 1px image into a 255px x 255px by changing the 7th and 9th bytes from 01 to FF, but that's as much as I could do to it.
      • Ahh, now I get it. If this is a serious problem I am guessing there are other ways to solve it too, like watermarking photos or using scripts that detect this kind of thing (searching for stop others linking images on google listed some sites).
        • Yeah... at least watermarking would let the people viewing it know where it came from. Of course, if your image is linked to a slashdot article, it won't show for long anyway :)

          I think there are some inherent problems with trying to use scripting to disallow deeplinking. I imagine it can all be done, but you'd have to spend some time making sure you weren't blocking legitimate GETs for that image.

          Personally, I believe your solution is the best.
  • The key piece of information that you're missing is that the size of the GIF is specified by 4 bytes, not just 2: 2 for width, 2 for height. The 7th and 8th bytes are for width, and the 9th and 10th bytes are for height. But be aware that the sizes have the least significant byte first. So to have a 430w x 543h image, you'd want the bytes like this: AE 01 1F 02.

    Here's a 65k x 65k transparent GIF in 43 bytes:

    47 49 46 38 39 61 ff ff ff ff 80 00 00 00 00 00
    ff ff ff 21 f9 04 01 00 00 01 00 2c 00 00 00 00
    01 00

    • Thanks.. I was having a hard time decyphering the code block layout in the doc I found... although given the size of the eventual GIF, I should have guessed 2 bytes. per axis.

      I tried it and it worked... chalk it up to another piece of knowledge gained... with your help :)
      • Wow, I didn't expect anyone to actually care about that post!

        Be careful with this newfound knowlege, I've gotten more than one forum user banned in more than one language using that. If you use it make sure to post a few links to your journal so we can all laugh at it. ;)

        Oh, and do NOT open that in an image editing program or you'll very quickly have all of your non-critical programs going to swap space. 65,536 pixels wide by 65,536 pixels tall equals 4,294,967,296 pixels total. Web browsers usually do fi
        • I like to tinker, wether it be with code or bytes, and your post really sparked it :)

          Thank you for the advice.. that could certainly prove helpful. I hope I don't ever need to use that idea, but if I do, the slashdot community will be the first to hear about it.

Always draw your curves, then plot your reading.

Working...