phoboslab / qoi

The “Quite OK Image Format” for fast, lossless image compression

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

MIME type?

marsf opened this issue · comments

It could be handled on the web (or implemented on any web browser), if QOI format has MIME type.
Can we use "image/x-qoi" as a proprietary media type of QOI?

The "regular" media types of iana.org is listed here.
https://www.iana.org/assignments/media-types/media-types.xhtml

Why would image/x-qoi be preferred to image/qoi?

Why would image/x-qoi be preferred to image/qoi?

Because, QOI has not yet authorized by standard related organization. Only such organization can apply the format type to iana.

On my thought, "image/qoi" is authorized as standard, and "image/x-qoi" is not authorized MIME type.

https://datatracker.ietf.org/doc/html/rfc2045#section-6.3

Implementors may, if necessary, define private Content-Transfer-
Encoding values, but must use an x-token, which is a name prefixed by
"X-", to indicate its non-standard status, e.g., "Content-Transfer-
Encoding: x-my-new-encoding".

Yeah, it seems that image/x-qoi would be the reasonable choice for now. For what it's worth, SerenityOS implemented it with image/x-qoi, too.

i use image/x-qoi and when searching for the "magic number" i also have it return image/x-qoi for the mime type (incase you are wondering i made a simple setup for

  1. creating a thumbnailer script for qoi
  2. creating the mimetype for thumbnailer to use
  3. regeristing the magic number and mime type with file
    all in my github repo
    )

it might be worthwhile using the IANA form at https://www.iana.org/form/media-types to register qoi.

That looks quite daunting. If we want QOI in the "standards tree" (i.e. image/qoi) there are extensive requirements:

The standards tree is intended for types of general interest to the Internet community. Registrations in the standards tree MUST be either:

  1. in the case of registrations associated with IETF specifications, approved directly by the IESG, or
  2. registered by a recognized standards-related organization using the "Specification Required" IANA registration policy [RFC5226] (which implies Expert Review).

~ https://www.rfc-editor.org/rfc/rfc6838.html#section-3.1

Media types registered in the standards tree by the IETF itself MUST be published as RFCs

~ https://www.rfc-editor.org/rfc/rfc6838.html#section-4.10

With all the difficulties of registering a MIME type in the standards tree Wikipedia says:

According to RFC 6838 (published in January 2013), any use of types in the unregistered tree is strongly discouraged.

Funny enough, image/x-qoi seems to be in violation with all this. It should be image/x.qoi instead.

In addition, subtypes prefixed with x- or X- are no longer considered to be members of this tree.

But even then it's a big no-no. So you're not supposed to use unregistered types such as x-qoi, but registering a proper type in the standards tree seems to be infeasible from my point of view.

We probably could register in the vendor tree, though. Looking at the registered types in the vnd tree, maybe image/vnd.qoi would be appropriate, without specifying any name of a "vendor". Also, the meaning of the term "vendor" seems to be quite loose:

The terms "vendor" and "producer" are considered equivalent in the context. Industry consortia as well as non-commercial entities can register media types in the vendor tree.

In conclusion: image/vnd.qoi seems to be the way to go!?

I didn't know the RFC 6648:
Deprecating the "X-" Prefix and Similar Constructs in Application Protocols

There is some guidance and advise in Appendix B.

Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.

In conclusion: image/vnd.qoi seems to be the way to go!?

It seems the "vnd" tree is for the file format that handled by perticular product.

RFC4288 - 3.2 Vendor Tree

The vendor tree is used for media types associated with commercially
available products. "Vendor" or "producer" are construed as
equivalent and very broadly in this context.

A registration may be placed in the vendor tree by anyone who needs
to interchange files associated with the particular product.
However, the registration formally belongs to the vendor or
organization producing the software or file format being registered.
Changes to the specification will be made at their request, as
discussed in subsequent sections.

There is "prs" tree as an option.

RFC4288 - 3.3 Personal or Vanity Tree

Registrations for media types created experimentally or as part of
products that are not distributed commercially may be registered in
the personal or vanity tree. The registrations are distinguished by
the leading facet "prs.".

The owner of "personal" registrations and associated specifications
is the person or entity making the registration, or one to whom
responsibility has been transferred as described below.

image/prs.qoi or image/prs.quiteok.qoi?

commented

Why not simply image/qoi?

It seems the "vnd" tree is for the file format that handled by perticular product.

Many vnd mime types "escaped" their original product. The most popular image format in this tree is probably image/vnd.dwg.

There is "prs" tree as an option.

That would be quite the downer. I mean, the whole idea of having a registered mime type is to make it more official. Having a "this is just a personal, experimental thing; please don't use"-prefix really defeats this point.

Why not simply image/qoi?

Official registration is difficult. There's lot's of requirements for this; see my previous comment.

It's curious though, that neither image/webp (wikipedia) nor image/flif (wikipedia) is in the official IANA list of registered types. It seems that these (relatively) new formats just yoloed it and made it "official" by convention.

I'm tempted to do the same and just announce in the readme that the recommended mime type to use is image/qoi. The real registration with IANA may follow whenever. image/qoi is the most logical solution after all (imho).

after all what else could be image/qoi aside from the Quite Ok Image format

I recommend adding the MIME type definition into https://gitlab.freedesktop.org/xdg/shared-mime-info/-/blob/master/data/freedesktop.org.xml.in

It will help applications to recognize QOI format and the presence in shared-mime-info is important for further support.

xdg, gimp and symfony use image/x-qoi.