Add recommendation for "JPEG or PNG" response

[pomakis]

Throughout the history of WMS and WMTS implementations, there's always been a conflict between whether to request JPEG images or PNG images. JPEG images are an order of magnitude smaller in byte size and therefore result in a much more responsive experience, but don't support transparency, so layer overlays are impossible. PNG images, however, do support transparency, but are much larger. Some client implementations deal with this by requesting the bottom layer as JPEG and all overlay layers as PNG, but this is far from ideal. One somewhat common solution is to support a "JPEG or PNG" format (represented by a requested content type of "image/x-jpegorpng" or "image/jpgpng" or a format string of "jop"). When this format is requested, the server can return the requested image the optimal image format (typically PNG if there's transparency and JPEG otherwise). Several implementations, including CubeWerx's, have taken this approach, and it has proven to be a highly effective optimization. However, the WMS and WMTS specifications failed to standardize such a request format, so this optimization isn't interoperable.

This isn't an issue for the "OGC API - Maps" and "OGC API - Tiles" standards, since, being much more RESTful in design, format (i.e., content type) negotiation is performed with the HTTP "Accept" request header. A client can simply indicate "Accept: image/png, image/jpeg", which literally means "give me whichever of these two formats you consider the most appropriate". And as a bonus, a typical web browser will send an Accept string which gives image/jpeg and image/png equal weighting, so JPEG-or-PNG negotiation can automatically occur even through simple web-browser requests.

However, my concern is that most implementers of the "OGC API - Maps" and "OGC API - Tiles" standards might not recognize the importance of this logic, and would likely write code which just chooses the first supported format in the list. I believe that awareness of this mechanism is important enough for it to be explicitly provided as a recommendation in both the "OGC API - Maps - Part 1: Core" and "OGC API - Tiles - Part 1: Core" standards.

In the "OGC API - Maps - Part 1: Core" standard, it could perhaps exist somewhere in section 21 ("Requirements classes for encodings"). My recommended wording is:

If both "image/png" and "image/jpeg" are supported at an endpoint and are present in the HTTP "Accept" request header with the same q value, and no other supported output format is present with a higher q value, the server should return the requested image in whichever of these two formats is considered optimal (typically PNG if there's transparency and JPEG otherwise).

(Of course, if servers implement an "f" parameter that overrides the HTTP "Accept" request header, they're free to support custom values such as "jop" or "image/x-jpegorpng" which trigger this optimization. However, since this is not a standardized parameter, the standards need not provide any recommendations to this effect.)

[ghobona]

Thanks @pomakis ! A recommendation or user guidance would be helpful. I presume that some implementers might consider including logic for selecting an compression optimisation (e.g. JPEG or PNG , with priority for lossless compression and some other constraint ...)

[IvanSanchez]

My stance is to take into account more recent image formats. In particular:

• image/avif, AVIF
• image/jpxl, JPEG-XL
• image/webp, WebP

As far as I can tell, these formats all support an alpha channel, and web browsers nowadays actually send a Accept: image/avif, image/webp, */* header, which means they prefer these formats.

[pomakis]

IIRC, we looked into supporting a couple of these formats a couple of years ago, but found that the writing/compression of such images was quite a bit slower than JPEG, causing slower responses and higher CPU loads. But yes, perhaps the recommendation could recommend support for one or more of these formats as well.

[IvanSanchez]

In regards to the q parameter of the Accept header, I think that a mere reference to the appropriate standard (which, in this case, is https://httpwg.org/specs/rfc9110.html#field.accept or https://www.rfc-editor.org/rfc/rfc9110.html#name-content-negotiation-fields ) should suffice.

I don't think there's any need for the OGC API specs to reiterate the HTTP specs; referencing them and reminding how they're used should be enough.

IMO, servers can and should apply a factor to the quality values of different formats, depending on the characteristics of the data being shown.

For example: if the resource is a typical rasterized topographic map with transparency, PNG would be preferred and JPG would be discouraged. The server can internally decide that JPG reduces quality by, let's say, 60% compared to a lossless format. Therefore, if a client requests Accept: image/jpg;q=1.0, image/png;q=0.8, the server will multiply the PNG weight by 1 and the JPG weight by 0.4. In the end PNG will "win" with a weight of 0.8 compared to the JPG weight of 0.4.

[joanma747]

The sprint ER has a section describing the issue: https://opengeospatial.github.io/ogcna-auto-review/22-054.html#toc31

In OGC API tiles a recommendation with this text was added:

"Recommendation 2 in OGC API Tiles: If both “image/png” and “image/jpeg” are supported at an endpoint and are present in the HTTP “Accept” request header with the same q value, and no other supported output format is present with a higher q value, the server SHOULD return the requested image in whichever of these two formats is considered optimal (typically PNG if there’s transparency or for categorical maps where a limited number of colors is used, and JPEG otherwise)."

That is: opengeospatial/ogcapi-tiles@dc56e5e

So we decided to do the same in OGC API maps.

[joanma747]

viewed in a telco