As storage is the main difficult thing in setting up a Panoramax instance on the long term, we have an open ticket about storage optimizations on Panoramax instance:
We’re exploring some options :
- change compression algorithms (see Exploring JPEG-XL)
- recompress the picture to a lower quality and/or resolution (selectively or globally)
etc… - avoid having double storage for 360° pictures (full original one, and its tiled version, by reconstruction the full one from the tiles)
This discussion goal is to summarize these options and what we plan to do in the short term.
JPEG-XL
The main issue here is its support by the clients. JPEG is universally supported by browsers and software as it is a standard that is now more than 30 years old !
JPEG-XL is not yet supported by default by browsers, except Safari (mobile and desktop). This is planned to change in the next version of Chrome and Firefox.
So for the moment, we’re exploring it, but we have no plan to switch to JPEG-XL in the short term and reconsider after monitoring deployment of native JPEG-XL support in the browsers and their adoption.
Recompress JPEG
We plan to change the quality factor when generating thumbnails, standard definition and tiled versions of the picture. Its value was set too high (95) generating some “fake quality” as the original pictures usually have something close to 70-80.
We plan to switch to quality levels of 70-80, and will also try to lower the quality on top/bottom tiles (sky, ground at 70) more than on the horizon (like 80).
In the table on Storage needs for a Panoramax instance, we can also see that the bits/pixel can range from 0.5 to almost 3.
Up to now, we’ve stick to a global rule of not changing the quality of the uploaded pictures, but in some cases this could be necessary to save storage space :
- it could be possible to set a limit on bits/pixel above which the pictures are recompressed for example at a standard quality level of 80.
- it could be ok to recompress the oldest pictures available in the area considering them as archives.
All this could also be tunable on each instance.
Tiled 360°
This is a huge point: 360° pictures are currently stored twice
- original : a full 360° image
- tiles : needed to have fast display on the viewer, and also reducing the amount of data downloaded (we usually have only 1/4 of the picture visible)
Which one should we keep ?
To maintain a fast display, the logical choice is to keep tiles, and reconstruct the full image on the fly. This reconstruction takes time and depending on the way it is done, can maintain the original pixels (by manipulating JPEG MCU using “drop” feature) or give a recompressed version.
If we switch to recreating the full image from tiles, this would imply to generate the tiles from MCU based crops of the original picture (pyturbojpeg has a multicrop that allows this), to maintain a pixel perfect copy and possible reconstruction.
What is currently missing in the equivalent “multidrop” that would take a bunch of tiles and merge them without recompression.
One last thing about tiles: currently the number of tiles depends on the picture resolution as the goal was to keep a more or less fixed amount of pixels around 1Mpx.
We’re going to change that and always cut them in 8x4, as the viewer always needs the same field of view which does not depend on the resolution.
This will also limit the number of requests on the server, and the global amount of data transferred will be very similar as well as the number and size of tiles which has also a performance impact on S3 storage (less requests) ans possibly on local filesystem based storage.
We hope that these next steps will help reducing the storage needs, step by step, without having major breaking changes.