search

w3c / png

Maintenance of the PNG specification
https://w3c.github.io/png/
Other
44 stars 11 forks source link

drag and drop / application interoperability #458

Open benjamin-otte opened 2 months ago

benjamin-otte commented 2 months ago

I'm currently in the process of implementing Colorspaces on the Gnome desktop and encountering the problem that legacy applications do not support iCCP or cICP chunks and display the PNG images wrong that I generated.

Of course, I could offer the data for them in an sRGB conformant PNG by mapping the pixels, but in particular in drag and drop implementations, I have no idea if applications need me to do that, because they all just use the "image/png" mime type.

It would be good if there was a way to achieve this interoperability that was recommended by this specification.

ProgramMax commented 2 months ago

I don't think there is a good answer to this here.

An application that only treats images as sRGB will only treat images as sRGB. Even if we add a new mime type to indicate additional functionality, it would still require the app to go beyond sRGB.

At the end of the day, the ONLY solutions are 1.) for the app to be aware of additional color spaces, or 2.) for the compositor to be aware of the app's behavior and accommodate. Neither of these can be addressed by the spec. Right?

benjamin-otte commented 2 months ago

What I'm trying to avoid is sending images to apps that aren't conforming. An example would be drag-and-dropping an image from a conformant browser or image editor into some old tool from 2010 that is used to make birthday invitations or something like that. That` application would advertise support for "image/png" but would not be able to handle anything new.

Going for a new mime type would allow defining a new conformance level in the spec and my application could provide an srgb image as "image/png" so that app keeps working while conformant apps would request the new mime type and get all the new features.

ProgramMax commented 2 months ago

Your app could also provide sRGB fallbacks within the existing png. But that would alter the png from the source app.

I can't think of any mime types which include version. Maybe there are some. But there are mime types that differentiate on features. APNG is one of them. However, introducing a new mime type for every new feature seems like it isn't the right solution.

Drag destination apps advertise mime types they support? That sounds like a new API could allow drag destination apps to also advertise the feature level they support. And that would be just as much effort from all parties as adding new mime types, right?

But I suspect you don't want to do that. So I think adding sRGB fallback chunks is the best option available.

svgeesus commented 2 months ago

Embedded ICC profiles have been part of the PNG spec since the 2003 Second Edition

Non-colormanaged apps are indeed an incredibly persistent pain to deal with. But if they haven't bothered to add support for anything beyond sRGB in two decades, it is unlikely they will be in any hurry to support new MIME types.

In addition, redefining the image/png and image/apng types to mean "sRGB only" is not backwards compatible. Existing apps (browsers, image editors) already accept ICC profiles and are starting to accept CICP as well.

I certainly feel, and share, the pain and frustration of non-colormanaged apps but the suggested solution would not, sadly, help with this.