<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="ltr">
<div>
<div dir="ltr">
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">I primarily want to get CDS’s views on this, to start with.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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<b></b>* one
of the existing standard types, thus with a net storage/cloud cost increase, not decrease. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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. </div>
<div dir="ltr"><br>
</div>
<div dir="ltr">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.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">Gregory</div>
</div>
</div>
<div id="ms-outlook-mobile-signature">
<div dir="ltr"><br>
</div>
Get <a href="https://aka.ms/o0ukef">Outlook for iOS</a></div>
<div id="mail-editor-reference-message-container" class="ms-outlook-mobile-reference-message">
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif"><b>From:</b> apps <apps-bounces@ivoa.net> on behalf of Markus Demleitner via apps <apps@ivoa.net><br>
<b>Sent:</b> Monday, March 3, 2025 23:17<br>
<b>To:</b> apps@ivoa.net <apps@ivoa.net><br>
<b>Subject:</b> Re: WebP in HiPS?
<div> </div>
</font></div>
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from text --><font size="2"><span style="font-size:11pt;">
<div class="PlainText">Dear Gregory,<br>
<br>
On Mon, Mar 03, 2025 at 08:25:30PM +0000, Dubois-Felsmann, Gregory P. via apps wrote:<br>
> However, the HiPS standard's language was not written in a way that<br>
> seems open to the _replacement_ of JPEG/PNG by WebP. The way the<br>
> tile-format metadata in the `properties` file is set up is<br>
> certainly extensible and compatible with it, but the words in the<br>
> standard itself are restrictive and prescriptive:<br>
<br>
I am fairly agnostic towards adding an image format or two to HiPS,<br>
but let me motivate why we should keep the list of supported image<br>
formats closed and short.<br>
<br>
HiPS is not only interpreted by Aladin lite and hence web browsers;<br>
there are also implementations running on conventional operating<br>
systems.<br>
<br>
They (practically) need to know which libraries they need up front<br>
and don't have the luxury of a runtime supporting a plethora of<br>
random image formats (but then don't share the danger that browser<br>
manufacturers suddenly pull the plug on something eminently<br>
reasonable:<br>
<a href="https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption)">https://en.wikipedia.org/wiki/JPEG_XL#Industry_support_and_adoption)</a>.<br>
<br>
I mention in passing that being open to all kinds of image formats is<br>
also a huge attack surface; a large fraction of serious<br>
non-javascript holes in web browsers were and are in image codecs,<br>
and you don't want to force all HiPS clients to have to pull these<br>
in, too.<br>
<br>
Hence, we should have good reasons to extend the list of supported<br>
image formats in HiPS. Two times better compression would count for<br>
me. 1.2 times better wouldn't. Standardised WCS would count; "but<br>
<company X> does it" wouldn't. "Supports lossy compression *and* an<br>
alpha channel" (which we don't have at the moment with PNG and JPEG)<br>
would convince me if Pierre tells me alpha channels are a good thing<br>
in HiPS.<br>
<br>
And I think I'd make "there are two independently maintained codecs<br>
out there" also a condition for letting something in (where I admit<br>
I'm not sure anyone has ever seen a need to re-implement libpng, so<br>
I'd not insist on making this a hard condition if the reference<br>
implementation is sufficiently community-supported).<br>
<br>
> In the mean time we will assume ".webp".<br>
><br>
> Also: my colleagues are asking: would you also plan to support<br>
> AVIF?<br>
<br>
After that, in both cases: Can you make the case why we should? And<br>
what's the implementation status of the formats in the relevant<br>
platforms (which, like it or not, still includes the JDK)?<br>
<br>
-- Markus<br>
<br>
</div>
</span></font></div>
</div>
</body>
</html>