4 ms·

Biggest image in the smallest space (2011)

• hinkley 3y ago
  Questions like this come in pretty handy for test fixtures. Sometimes you worry about the memory usage of a file to be processed, rather than the disk usage. If you can make a fixture that is substantially smaller on the outside, you can just check it into version control instead of having to fiddle with generating them or storing them in some external store, where they tend to rot. What does our code signing library do with 2,4,20GB compressed files? What does our image upload tool do if you give it a 50 megapixel picture of blue sky? What if our customer is just trying to be an asshole? All good integration tests to run.
  • kadoban 3y ago
    > If you can make a fixture that is substantially smaller on the outside, you can just check it into version control instead of having to fiddle with generating them or storing them in some external store, where they tend to rot. You _can_ check fairly large files into version control without any real issues, especially if you're aware of the limitations. For example, in git, if you have a 20GB file that never (or rarely) changes, it'll work great. The only real reason to avoid that would be if most people who clone the repo won't need that file, or if your repo host (eg github) gets mad. There's certainly times you'd want to avoid it and find other solutions, but it should be a tool in the box when needed IMO, and a lot of people just don't even consider it.
    • cebert 3y ago
      Git LFS isn’t a bad route to go either.
• deleted 3y ago
  [deleted]
• teddyh 3y ago
  > The PNG file is further bzip2-compressed to avoid abuse by people hot-linking it in img elements. You could fix that by requiring a “Referer” header with appropriate content.
• zakki 3y ago
  I can't open the png file in Mac's Preview and Safari.