search

FLIF-hub / FLIF

Free Lossless Image Format
Other
3.72k stars 229 forks source link

Partially progressive.. #377

Open PallHaraldsson opened 7 years ago

PallHaraldsson commented 7 years ago

Since progrssive is slow much slower #333 is it possible to start already with say quarter-size (in each direction), or something like low resolution smartphone-sized for the first bytes and then progressively thereafter up to full image size.

This is just an idea. Maybe the fileformat doesn't allow (yet), but the concept does and should?

hrj commented 7 years ago

According to the spec, the bitstream has a parameter called first_zl, which specifies the zoom level of the "rough preview". This could be exposed via a command line parameter to make it configurable by the user.

@jonsneyers If that sounds right, I could submit a PR.

jonsneyers commented 7 years ago

The "rough preview" pixels have worse compression, because they are all encoded using just one MANIAC context per channel. They are encoded before the MANIAC trees are encoded; the advantage is that you can in principle use a simpler decoder and you get the pixels very early in the bitstream. But I wouldn't use this to encode any large amount of pixels.

The main reason progressive is slower is because the transformations are undone multiple times. You can already control (kinda) when you want to get callbacks, and https://github.com/FLIF-hub/FLIF/pull/383 further improved the situation. If you just avoid doing too many actual renderings, progressive decoding shouldn't be too much slower.

jonsneyers commented 7 years ago

But yeah, exposing the "rough preview" zoomlevel as a command line parameter sounds like a good idea, it might be worthwhile to experiment a bit with that too.