t0rakka

What do you mean and? The implications are implicit; any vulnerability will be unpatched, so bad actor (tm) has to know only ONE vulnerability after XP support was ceased. If he has means of talking to the machine through TCP/IP or UDP he will have 100% guaranteed access.

You wouldn't believe how much traffic is hammering IP ranges with known vulnerabilities. Forward port 22 to your Linux box or similar, check the logs for number of "connection attempts", it's going to be glorious log. A-HOLES of this planet are doing this just to get control of devices connected to the internet, if for no other reason than use them in DDoS-for-hire service. If there is a quick buck to be made.. they'll be all over it. Human parasites.

I wrote a small test bench for my own uses as wanted to compare with different codecs and see how "raw compression" would work, how would QOI+ZSTD combination work and so on.

Here's example output..

  image: 1502 x 1800 ( 10560 KB )
  ----------------------------------------------
           encode(ms)  decode(ms)   size(KB)    
  ----------------------------------------------
  qoi:          31.2        21.6       2452  
  qoi+zstd:     46.7        19.3       1832  
  zstd:         47.4         8.7       2742  
  lz4:          14.1         3.0       4108  
  png:          92.4        18.0       2795  
  zpng:         24.1        13.3       1394  
  jpg:           2.7         1.8        517  <-- lossy
  webp:        199.6        19.1        227  <-- lossy

Guilty as charged.. the 1% was a napkin estimate.

The True Cost in this specific case is (0..7 bits to fill a byte) + 2 bytes for the RST marker for each interval. 320x240 image and RST interval for each 240/8 block means 30 RST's so something close to 75 bytes "wasted", or, other way to look at it is ~3 bits per row.

The reason is that for the JPEG the Huffman tree is fixed and is transmitted with the image data so restarting is cheap; it does not start from scratch and build a new tree each time; each decoded symbol is also independent so you can stop and restart at any time you want. I don't have any ANS experience at all so won't say anything about that.. but it would be nice if some sort of way would be possible to isolate the ranges.

Good observations, btw. :)

Found the file. 230 ms decode and 96 ms encode on i9 7900x. :)

Timings with the original test image ( https://www.eso.org/public/archives/print_posters/large/prin... )

9933 x 7016 (7.4 MB)

    load turbojpeg: 309 ms 
    load mango:     225 ms
    save turbojpeg: 388 ms
    save mango:     96 ms

Started with 800 ms save time earlier today but got motivated to finally optimize the encoder; thanks! :)