WebP in HiPS?

[Dubois-Felsmann, Gregory P.]

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20250304/ffa4e96b/attachment-0001.htm>