WebP in HiPS?

[Markus Demleitner]

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).

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