WebP in HiPS?

[Laurent Michel]

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
-- 
jesuischarlie/Tunis/Paris/Bruxelles/Berlin

Laurent Michel
SSC XMM-Newton
Tél : +33 (0)3 68 85 24 37
Fax : +33 (0)3 )3 68 85 24 32
Université de Strasbourg <http://www.unistra.fr>
Observatoire Astronomique
11 Rue de l'Université
F - 67200 Strasbourg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Capture d??cran de 2025-03-04 13-57-14.png
Type: image/png
Size: 70486 bytes
Desc: not available
URL: <http://mail.ivoa.net/pipermail/apps/attachments/20250304/6d12c9ca/attachment-0001.png>