6 ms·

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are

I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, and of course more if you are using multiple threads. Anyway, yes, we should improve decode speed — for example, currently every sample value is unnecessarily converted from int to float and then back to int, and obviously that causes some avoidable slowdowns. I agree that MT PNG does have a gentler transition path than introducing a new format. The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, which can be hard given how many existing deployments of png there are. Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc. Also one disadvantage of MT PNG compared to JXL is that it splits the image in stripes, not tiles. For full-image decode, that doesn't matter much, but for region-of-interest (cropped) decode, tiles are a bit more efficient (no need to unnecessarily decode the areas to the left and right of the region of interest).

nigeltao 4y ago
> I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, In case it wasn't clear, the 0.630 fjxl encode speed number in the top level README.md in that commit is after normalization such that QOIR is 1.000. After all, absolute numbers are hardware dependent. If you look at the doc/full_benchmarks.txt change in the same commit I linked to, fjxl encode speed clocks at 106.48 megapixels per second. It's just that QOIR encode speed clocks at 168.90 megapixels per second (and fpnge at 312.59).
nigeltao 4y ago
> The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, Well, for PNG, Apple have shipped exactly that. It was something they could unilaterally do without e.g. having to get all of the major browser makers on board. Apple's PNG encoders (i.e iOS dev SDKs) produce multi-thread-friendly PNGs and their decoders (i.e. iOS devices) reap the benefits. And unlike trying to introduce a new but not-backwards-compatible-with-PNG format (JPEG-XL), other PNG decoders can still decode these images. They just don't get the speed benefit. > Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc. It's forwards compatible too. Apple's PNG decoder will use MT decode if the PNG image was encoded with MT metadata, but Apple's PNG decoder can still decode arbitrary PNG (using its pre-existing single-thread code path).

nigeltao 4y ago

> I think you must be doing something very wrong if you measure less than 1 Mpx/s for fjxl. It should reach at least 50 Mpx/s or so, In case it wasn't clear, the 0.630 fjxl encode speed number in the top level README.md in that commit is after normalization such that QOIR is 1.000. After all, absolute numbers are hardware dependent. If you look at the doc/full_benchmarks.txt change in the same commit I linked to, fjxl encode speed clocks at 106.48 megapixels per second. It's just that QOIR encode speed clocks at 168.90 megapixels per second (and fpnge at 312.59).

nigeltao 4y ago

> The point remains though that you need to somehow get both the encoder side and the decoder side upgraded to benefit from the advantage, Well, for PNG, Apple have shipped exactly that. It was something they could unilaterally do without e.g. having to get all of the major browser makers on board. Apple's PNG encoders (i.e iOS dev SDKs) produce multi-thread-friendly PNGs and their decoders (i.e. iOS devices) reap the benefits. And unlike trying to introduce a new but not-backwards-compatible-with-PNG format (JPEG-XL), other PNG decoders can still decode these images. They just don't get the speed benefit. > Any system that has to take arbitrary png as input cannot rely on MT decode being an option, etc. It's forwards compatible too. Apple's PNG decoder will use MT decode if the PNG image was encoded with MT metadata, but Apple's PNG decoder can still decode arbitrary PNG (using its pre-existing single-thread code path).