5 ms·

I came away from reading the article wondering what context I was missing. What use-case is the author targeting? It feels like I need to read more about this a

by jitl 4y ago

I came away from reading the article wondering what context I was missing. What use-case is the author targeting? It feels like I need to read more about this author to understand the article.

dmix 4y ago
It reminds me of that Steve Jobs insult thread, it’s a technology looking for an audience. The pitch as I can tell is that the specification is simple. So the guy who spends a lot of time writing code based on specifications likes it? I guess that’s the niche audience. Maybe a better pitch would be “image format specifications should be more like QOI”.
bscphil 4y ago
I think it's in the title: assets. The example case is replacing the BMP assets used by a game with QOI with a resulting 10x size reduction: https://github.com/skeeto/chess/commit/5c123b3 https://github.com/skeeto/chess/commit/5c123b3 I think this functions as a test case. For a game as simple as a chess UI, PNG would probably be fine unless you're code-golfing on the final output binary size or refusing to use common dependencies. But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial. Maybe the assets could even be left in compressed form in memory in order to reduce the system requirements? I'm not sure if this is common or not. Side note: video game assets are often enormous in size because developers refuse to implement even very basic compression because of the supposed performance impact. Getting the decompression speed up can result in tremendous reduction in disk usage because it allows doing compression without losing performance.
- duskwuff 4y ago
  > But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial. Those games typically don't need lossless image compression. There are much better (and faster) algorithms for lossy texture compression, many of which can even be decoded directly by the GPU. The S3TC family is one popular example. One interesting commercial product in this space is Oodle Texture: http://www.radgametools.com/oodletexture.htm http://www.radgametools.com/oodletexture.htm
  - bscphil 4y ago
    It's true that lossless is often not the best approach, although it's worth pointing out that anyone can implement Quite OK while both the approaches you mention are not really friendly to open source.
    - duskwuff 4y ago
      S3TC is patent-free as of October 2017, and is implemented in open-source graphics drivers.
      - bscphil 4y ago
        Are the best available compressors for the format open source as well? That would be news to me, although I admit I haven't looked into the format in quite some time. More generally, my point about video games was just that you can frequently cut their size by 50-75% just by turning on file compression on the game directory. Developers are obviously missing some easy wins in this area - including huge wins with lossless compression alone.
        ImHereToVote 4y ago
        Use Universal Basis
        slimsag 4y ago
        basisu (Binomial's Basis Universal GPU Texture Codec) is pretty much state of the art here. Open source, offers excellent compression and very quickly decodes to pretty much all GPU native formats.
        iainmerrick 4y ago
        basisu is really impressive, but it’s not perfect for all use cases. I tried using it in a WebGL game, but found that a) decoding was too slow, and b) the quality was too low. PNG is much bigger, so you’d think it wouldn’t be good for a web game, but once an image has been downloaded and cached, the most important factor is the decode-and-upload time. On the web, PNG and JPEG handily beat basisu there. In a different situation, basisu could have worked out for me. On native rather than web, maybe the decode time would have been fine. With more photographic rather than geometric assets, maybe the quality would have been fine.
- flohofwoe 4y ago
  > video game assets are often enormous in size because developers refuse to implement even very basic compression because of the supposed performance impact This claim needs some real world evidence to back it up (and usually it's not about a performance impact, but instead a perceived image quality impact). IME a lot of care is taken for compressing asset data, and if there would be a chance to reduce the asset size by another few percent without losing too much detail (that's the important part), it would be done. In the end, textures need to end up in memory as one of the GPU compatible hardware compressed texture formats (e.g. BCx) - which is important not only for reducing memory usage, but mainly for increasing texture sampling performance on the GPU (reduced memory bandwidth and better cache locality when reading texture data from GPU memory). Those hardware-compressed texture formats rule out any of the popular image formats like JPEG, PNG etc... that might have a better overall compression, but are hard to decode on the fly to one of the hardware texture formats (but there are now alternatives like https://github.com/BinomialLLC/basis_universal https://github.com/BinomialLLC/basis_universal), but even a generic lossless compressor (even good old zip) on top of BCx is already a good start.
  - bscphil 4y ago
    > This claim needs some real world evidence to back it up (and usually it's not about a performance impact, but instead a perceived image quality impact). We're talking lossless compression here, so image quality is not the issue. Fortunately someone else has already done this research. There's a tool for Windows to control the compact.exe behavior for individual folders called CompactGUI: https://github.com/IridiumIO/CompactGUI https://github.com/IridiumIO/CompactGUI They maintain a database of compression results here: https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJUGaoUzhC5titIC1rzQHI4yI/edit#gid=0 https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJ... Reductions in storage use of greater than 50% are so common that they're hardly even worth remarking on. My experience with compressing a bunch of games is that the biggest gains come from compressing bloated asset packs. Hard to know what else could be taking up more than 50% of the storage space in a particular game.
    - flohofwoe 4y ago
- willis936 4y ago
  What performance penalty? Decoding is often faster than moving more bits from storage.
- maccard 4y ago
  > I'm not sure if this is common or not. > Side note: video game assets are often enormous in size because developers refuse to implement even very basic compression Be generous; you even said in your previous sentence you don't know if it's common or not, so how do you know developers refuse to implement basic compression? If it's that easy, I'm sure there are plenty of AAA game studios (including mine) that will hire you to just implement basic compression. There are enormous tradeoffs to make that are platform dependent; read speeds from external media are _incredibly_ slow but from internal media may be fast. Some assets are stored on disk to mask loading/decompression. Lastly, assets are just enormous these days. A single 4k texture is just shy of 70MB before compression and a modern game is going to be made of a large number of these (likely hundreds of them), and many games are shipping with HDR - these are multiples of the size. That's becore you get to audio, animation, 3d models, or anything else. My current projects source assets are roughly 300Gb, and our on disk size is 3GB or so. My last project was 5Tb of source assets and 60GB on disk. Of course we're using compression.
  - bscphil 4y ago
    > Be generous; you even said in your previous sentence you don't know if it's common or not, so how do you know developers refuse to implement basic compression? If it's that easy, I'm sure there are plenty of AAA game studios (including mine) that will hire you to just implement basic compression. The thing I said I didn't know whether it was common was keeping assets in compressed form in memory. I admit I don't know much of the specifics of how game rendering works. What I do know something about is the extremely poor compression applied to many video games in their on-disk form. I'm willing to grant that your studio may indeed be an exception to this, but the general principle isn't possible to deny. Just by enabling lossless Windows file compression on a game folder, you can frequently see the size of a game on disk drop by 50% or more, as I discuss in my comment here: https://news.ycombinator.com/item?id=34042164 https://news.ycombinator.com/item?id=34042164 Surely a lossless format designed specifically for encoding assets would be even more effective and fast than generic Windows file compression!
  - jcpham2 4y ago
    I was trying to explain to my son the other day when he was complaining about the Xbox without the drive slot. I asked him how big of a download Fortnite or call of duty were - I think he said 60 gigs and then I told him blu ray tops out at 50gb. He understands why the Xbox doesn’t have the cd slot anymore.
atoav 4y ago
In the first paragraph they say: > QOI has become my default choice for embedded image assets. Embedded means they are working on stuff with low amounts of storage, computing speed and memory. If you are developing for embedded you are developing for electronics products typicyally. Every byte you can shave off can ultimately increase the return on investment. Using a traditional image format on embedded might not be possible because you don't have the program memory to store a complex decoder. If you decoder is 10 times bigger than the assets it is meant to decode, maybe there is not so much benefit in using it. The simplest decoder you can go with would be just storing the value of the pixels in a bitmap and teading that out of that array. This however has the downside that you got no compression on the assets at all. If you have very simple color spaces (e.g. 1bit), tiny resolutions and few assets this might be an acceptable choice, but the choice gets worse as you get more assets, higher resolutions more channels or more bits per channel. That means according to the author there is a space between just storing bitmaps and just using a png decoder where there were no good goto solutions before and they found a good solution with QOI.
- Dylan16807 4y ago
  > That means according to the author there is a space between just storing bitmaps and just using a png decoder where there were no good goto solutions before and they found a good solution with QOI. What space? I feel like that's an assumption you're making and it might be true or it might not be, but even if you're right that's very vague and I want more specificity.
  - pizza 4y ago
    QOI lies between uncompressed images and entropy coded compressed images. It also happens to work heuristically quite well for such a simple spec. Maybe its defining feature is its simplicity, foremost (and as a consequence of that, speed, secondarily)
    - Dylan16807 4y ago
      I know where it lies on the compression spectrum, I'm asking what use case prefers it.

by jitl 4y ago

I came away from reading the article wondering what context I was missing. What use-case is the author targeting? It feels like I need to read more about this author to understand the article.

dmix 4y ago

It reminds me of that Steve Jobs insult thread, it’s a technology looking for an audience. The pitch as I can tell is that the specification is simple. So the guy who spends a lot of time writing code based on specifications likes it? I guess that’s the niche audience. Maybe a better pitch would be “image format specifications should be more like QOI”.

bscphil 4y ago

I think it's in the title: assets. The example case is replacing the BMP assets used by a game with QOI with a resulting 10x size reduction: https://github.com/skeeto/chess/commit/5c123b3 https://github.com/skeeto/chess/commit/5c123b3 I think this functions as a test case. For a game as simple as a chess UI, PNG would probably be fine unless you're code-golfing on the final output binary size or refusing to use common dependencies. But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial. Maybe the assets could even be left in compressed form in memory in order to reduce the system requirements? I'm not sure if this is common or not. Side note: video game assets are often enormous in size because developers refuse to implement even very basic compression because of the supposed performance impact. Getting the decompression speed up can result in tremendous reduction in disk usage because it allows doing compression without losing performance.

duskwuff 4y ago
> But for some programs (e.g. large video games), preloading all your assets is very common and decoding speed can be crucial. Those games typically don't need lossless image compression. There are much better (and faster) algorithms for lossy texture compression, many of which can even be decoded directly by the GPU. The S3TC family is one popular example. One interesting commercial product in this space is Oodle Texture: http://www.radgametools.com/oodletexture.htm http://www.radgametools.com/oodletexture.htm
- bscphil 4y ago
  It's true that lossless is often not the best approach, although it's worth pointing out that anyone can implement Quite OK while both the approaches you mention are not really friendly to open source.
  - duskwuff 4y ago
    S3TC is patent-free as of October 2017, and is implemented in open-source graphics drivers.
    - bscphil 4y ago
      Are the best available compressors for the format open source as well? That would be news to me, although I admit I haven't looked into the format in quite some time. More generally, my point about video games was just that you can frequently cut their size by 50-75% just by turning on file compression on the game directory. Developers are obviously missing some easy wins in this area - including huge wins with lossless compression alone.
      - ImHereToVote 4y ago
        Use Universal Basis
      - slimsag 4y ago
        basisu (Binomial's Basis Universal GPU Texture Codec) is pretty much state of the art here. Open source, offers excellent compression and very quickly decodes to pretty much all GPU native formats.
        iainmerrick 4y ago
        basisu is really impressive, but it’s not perfect for all use cases. I tried using it in a WebGL game, but found that a) decoding was too slow, and b) the quality was too low. PNG is much bigger, so you’d think it wouldn’t be good for a web game, but once an image has been downloaded and cached, the most important factor is the decode-and-upload time. On the web, PNG and JPEG handily beat basisu there. In a different situation, basisu could have worked out for me. On native rather than web, maybe the decode time would have been fine. With more photographic rather than geometric assets, maybe the quality would have been fine.
flohofwoe 4y ago
> video game assets are often enormous in size because developers refuse to implement even very basic compression because of the supposed performance impact This claim needs some real world evidence to back it up (and usually it's not about a performance impact, but instead a perceived image quality impact). IME a lot of care is taken for compressing asset data, and if there would be a chance to reduce the asset size by another few percent without losing too much detail (that's the important part), it would be done. In the end, textures need to end up in memory as one of the GPU compatible hardware compressed texture formats (e.g. BCx) - which is important not only for reducing memory usage, but mainly for increasing texture sampling performance on the GPU (reduced memory bandwidth and better cache locality when reading texture data from GPU memory). Those hardware-compressed texture formats rule out any of the popular image formats like JPEG, PNG etc... that might have a better overall compression, but are hard to decode on the fly to one of the hardware texture formats (but there are now alternatives like https://github.com/BinomialLLC/basis_universal https://github.com/BinomialLLC/basis_universal), but even a generic lossless compressor (even good old zip) on top of BCx is already a good start.
- bscphil 4y ago
  > This claim needs some real world evidence to back it up (and usually it's not about a performance impact, but instead a perceived image quality impact). We're talking lossless compression here, so image quality is not the issue. Fortunately someone else has already done this research. There's a tool for Windows to control the compact.exe behavior for individual folders called CompactGUI: https://github.com/IridiumIO/CompactGUI https://github.com/IridiumIO/CompactGUI They maintain a database of compression results here: https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJUGaoUzhC5titIC1rzQHI4yI/edit#gid=0 https://docs.google.com/spreadsheets/d/14CVXd6PTIYE9XlNpRsxJ... Reductions in storage use of greater than 50% are so common that they're hardly even worth remarking on. My experience with compressing a bunch of games is that the biggest gains come from compressing bloated asset packs. Hard to know what else could be taking up more than 50% of the storage space in a particular game.
  - flohofwoe 4y ago
willis936 4y ago
What performance penalty? Decoding is often faster than moving more bits from storage.
maccard 4y ago
> I'm not sure if this is common or not. > Side note: video game assets are often enormous in size because developers refuse to implement even very basic compression Be generous; you even said in your previous sentence you don't know if it's common or not, so how do you know developers refuse to implement basic compression? If it's that easy, I'm sure there are plenty of AAA game studios (including mine) that will hire you to just implement basic compression. There are enormous tradeoffs to make that are platform dependent; read speeds from external media are _incredibly_ slow but from internal media may be fast. Some assets are stored on disk to mask loading/decompression. Lastly, assets are just enormous these days. A single 4k texture is just shy of 70MB before compression and a modern game is going to be made of a large number of these (likely hundreds of them), and many games are shipping with HDR - these are multiples of the size. That's becore you get to audio, animation, 3d models, or anything else. My current projects source assets are roughly 300Gb, and our on disk size is 3GB or so. My last project was 5Tb of source assets and 60GB on disk. Of course we're using compression.
- bscphil 4y ago
  > Be generous; you even said in your previous sentence you don't know if it's common or not, so how do you know developers refuse to implement basic compression? If it's that easy, I'm sure there are plenty of AAA game studios (including mine) that will hire you to just implement basic compression. The thing I said I didn't know whether it was common was keeping assets in compressed form in memory. I admit I don't know much of the specifics of how game rendering works. What I do know something about is the extremely poor compression applied to many video games in their on-disk form. I'm willing to grant that your studio may indeed be an exception to this, but the general principle isn't possible to deny. Just by enabling lossless Windows file compression on a game folder, you can frequently see the size of a game on disk drop by 50% or more, as I discuss in my comment here: https://news.ycombinator.com/item?id=34042164 https://news.ycombinator.com/item?id=34042164 Surely a lossless format designed specifically for encoding assets would be even more effective and fast than generic Windows file compression!
- jcpham2 4y ago
  I was trying to explain to my son the other day when he was complaining about the Xbox without the drive slot. I asked him how big of a download Fortnite or call of duty were - I think he said 60 gigs and then I told him blu ray tops out at 50gb. He understands why the Xbox doesn’t have the cd slot anymore.

atoav 4y ago

In the first paragraph they say: > QOI has become my default choice for embedded image assets. Embedded means they are working on stuff with low amounts of storage, computing speed and memory. If you are developing for embedded you are developing for electronics products typicyally. Every byte you can shave off can ultimately increase the return on investment. Using a traditional image format on embedded might not be possible because you don't have the program memory to store a complex decoder. If you decoder is 10 times bigger than the assets it is meant to decode, maybe there is not so much benefit in using it. The simplest decoder you can go with would be just storing the value of the pixels in a bitmap and teading that out of that array. This however has the downside that you got no compression on the assets at all. If you have very simple color spaces (e.g. 1bit), tiny resolutions and few assets this might be an acceptable choice, but the choice gets worse as you get more assets, higher resolutions more channels or more bits per channel. That means according to the author there is a space between just storing bitmaps and just using a png decoder where there were no good goto solutions before and they found a good solution with QOI.

Dylan16807 4y ago
> That means according to the author there is a space between just storing bitmaps and just using a png decoder where there were no good goto solutions before and they found a good solution with QOI. What space? I feel like that's an assumption you're making and it might be true or it might not be, but even if you're right that's very vague and I want more specificity.
- pizza 4y ago
  QOI lies between uncompressed images and entropy coded compressed images. It also happens to work heuristically quite well for such a simple spec. Maybe its defining feature is its simplicity, foremost (and as a consequence of that, speed, secondarily)
  - Dylan16807 4y ago
    I know where it lies on the compression spectrum, I'm asking what use case prefers it.