WebP in HiPS?

[Pierre Fernique]

Hi all,

/    short answer: why not add webp, but before we encourage that, let's 
weigh up the pros and cons..
     Long answer:
/

First of all, an important reminder for those unfamiliar with the HiPS 
standard: a HiPS can be distributed simultaneously in several tile 
formats, typically FITS and PNG for HiPS images. And the list of HiPS 
tile formats in the HiPS 1.0 document is indicative and deliberately not 
exhaustive. The policy expressed by the authors of the HiPS 1.0 document 
tends to reconcile these two criteria:

1 – *Cover current and future use cases.* This point tends to take into 
account several tile formats (FITS for direct pixel access to full 
dynamic range, PNG for a high-compression visual alternative, TSV for 
catalog tiles, etc.)

And it seems perfectly reasonable to add the formats needed to cover new 
requirements. For example, “parquet” for the use of HiPS for 
partitioning rather than visualization (= HATS initiative). Or FITS3D 
and APNG or equivalent for current work on HiPS3D.

But this first criterion is tempered by a second important one:

2 - *Ensure the widest possible match between HiPS products and 
compatible clients*. This point tends to limit the number of tile formats.

Duplication of formats should be avoided as a matter of principle. And 
the replacement of a format meeting a particular need already covered 
must be sufficiently justified. And if this is the case (e.g. PNG 
gradually replacing JPEG to benefit from a transparency channel (*) ), a 
transition phase is necessary to give customers (and HiPS generation 
tools) time to implement the replacement format. This transition phase 
is costly, as it involves the duplication of tiles (old and new 
formats), and time-consuming (convincing customers of the benefits of 
switching to the new format (e.g. PNG instead of JPEG)).

0 - There's also a prerequisite: *use only widely known formats,* 
displayable/readable independently of the HiPS ecosystem. The aim is to 
facilitate implementation (from the point of view of both generation and 
clients).

In fact, most of these principles have already been taken up in Markus' 
answer


Now that we've recalled these principles, *what are the justifications 
for a new evolution/addition* to the tile format for visualizing lossy 
compressed data, i.e. offering an alternative to JPEG and/or PNG to 
webp? Thomas Boch has carried out several full-scale tests, and I'll let 
him tell you the results. We'll then be able to decide, at IVOA level, 
whether or not it's justified to encourage this new format as an 
alternative, or even a replacement.

The AVIF format was also mentioned. For our part at CDS, we haven't 
tested this format. The fact that it offers better dynamic range 
coverage would indeed be a plus, but this would have to be demonstrated 
beforehand (a property generally incompatible with a good compression 
factor).

Finally, the point about the keyword to be used “png, jpg, fits, ....” 
for the keyword “hips_tile_format”, it *seems reasonable to me to 
suggest “webp”* since this is the extension usually used. And if 
necessary, to write a short Endorsed Note to avoid divergences. The 
remark about the “ bad ‘ choice of ’ jpeg ‘ instead of ’ jpg ” is quite 
pertinent. This could be addressed in an Errata.

(*) For @Markus, PNG was proposed for the importance of an alpha channel 
and not specifically for lossless compression. In fact, whether in JPEG 
or PNG, you have to apply a cut (8bits) and therefore necessarily 
introduce a large loss of information compared with the original pixels.

Pierre


Le 04/03/2025 à 14:05, Laurent Michel via apps a écrit :
> Hello,
>
> For the record, the transparency is already supported for PNG 
> (blank=xyz parameter of HipsGen)
> I join an XMM image of Mkr 993 as shown by Aladin Lite V3 where we can 
> see that the CCD gaps are transparent.
> This feature has ben requested longtime ago to enhance the rendering 
> of stacked images
>
> Laurent
>
>
>
>
> Le 04/03/2025 à 09:33, Dubois-Felsmann, Gregory P. via apps a écrit :
>> I’m mainly acting as an intermediary here, representing colleagues 
>> not so familiar with IVOA processes. We received a suggestion that we 
>> support HiPS-via-WebP in Firefly, which I didn’t want to do just by 
>> guessing, without some written support. Even more did I not want the 
>> project to publish datasets described as “HiPS” that were not 
>> conformant.
>>
>> I primarily want to get CDS’s views on this, to start with.
>>
>> With regard to your “why” question, the (relatively small) size 
>> reduction was probably the main motivation from my Rubin colleagues, 
>> but I noted that without support from the standard, we’d at best be 
>> stuck providing *both* WebP  *and*​*​* one of the existing standard 
>> types, thus with a net storage/cloud cost increase, not decrease.
>>
>>  From another point of view, I think supporting both compression and 
>> transparency could be valuable for HiPS that are partial-sky, making 
>> it easier for clients to "stack" them. I'd certainly like to hear 
>> CDS' take on that, though.
>>
>> Regarding AVIF, about which I know essentially nothing, what I'm told 
>> is that it would facilitate providing high-dynamic-range imaging in a 
>> compressible format. It is a fairly well-known issue with HiPS as it 
>> is that it's difficult to scale a JPEG/PNG-based HiPS image so that 
>> it provides a good visualization experience both in bright 
>> Galactic-plane regions and in sparsely populated regions.
>>
>> Gregory
>>
>> Get Outlook for iOS <https://aka.ms/o0ukef>
>> -------------------------------------------------------------------------------------------------------------------------------- 
>>
>> *From:* apps <apps-bounces at ivoa.net> on behalf of Markus Demleitner 
>> via apps <apps at ivoa.net>
>> *Sent:* Monday, March 3, 2025 23:17
>> *To:* apps at ivoa.net <apps at ivoa.net>
>> *Subject:* Re: WebP in HiPS?
>> Dear Gregory,
>>
>> On Mon, Mar 03, 2025 at 08:25:30PM +0000, Dubois-Felsmann, Gregory P. 
>> via apps wrote:
>>> However, the HiPS standard's language was not written in a way that
>>> seems open to the _replacement_ of JPEG/PNG by WebP.  The way the
>>> tile-format metadata in the `properties` file is set up is
>>> certainly extensible and compatible with it, but the words in the
>>> standard itself are restrictive and prescriptive:
>>
>> I am fairly agnostic towards adding an image format or two to HiPS,
>> but let me motivate why we should keep the list of supported image
>> formats closed and short.
>>
>> HiPS is not only interpreted by Aladin lite and hence web browsers;
>> there are also implementations running on conventional operating
>> systems.
>>
>> They (practically) need to know which libraries they need up front
>> and don't have the luxury of a runtime supporting a plethora of
>> random image formats (but then don't share the danger that browser
>> manufacturers suddenly pull the plug on something eminently
>> reasonable:
>> https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption) 
>> <https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption)>.
>>
>> I mention in passing that being open to all kinds of image formats is
>> also a huge attack surface; a large fraction of serious
>> non-javascript holes in web browsers were and are in image codecs,
>> and you don't want to force all HiPS clients to have to pull these
>> in, too.
>>
>> Hence, we should have good reasons to extend the list of supported
>> image formats in HiPS.  Two times better compression would count for
>> me.  1.2 times better wouldn't.  Standardised WCS would count; "but
>> <company X> does it" wouldn't.  "Supports lossy compression *and* an
>> alpha channel" (which we don't have at the moment with PNG and JPEG)
>> would convince me if Pierre tells me alpha channels are a good thing
>> in HiPS.
>>
>> And I think I'd make "there are two independently maintained codecs
>> out there" also a condition for letting something in (where I admit
>> I'm not sure anyone has ever seen a need to re-implement libpng, so
>> I'd not insist on making this a hard condition if the reference
>> implementation is sufficiently community-supported).
>>
>>> In the mean time we will assume ".webp".
>>>
>>> Also: my colleagues are asking: would you also plan to support
>>> AVIF?
>>
>> After that, in both cases: Can you make the case why we should? And
>> what's the implementation status of the formats in the relevant
>> platforms (which, like it or not, still includes the JDK)?
>>
>>          -- Markus
>>
>
> -- 
> English version: https: //www.deepl.com/translator
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20250304/095eacfe/attachment-0001.htm>