Bug 8170

Created attachment 6864 [details]
mime type for digital cameras' raw images

Created attachment 7518 [details]
mime types for digital cameras' raw images

Added a DNG mime type.

I guess, that application/x-ufraw is application specific file and maybe should
be packaged with ufraw package, not with freedesktop.org.xml.

image/x-dcraw seems to be superseded by particular MIME types and does not have
real reason to exist in this form (description does not contain any other magic
or suffixes). Maybe it can be handled better in future as a virtual MIME type:
http://lists.freedesktop.org/archives/xdg/2006-October/008666.html
or you can use not yet separately handled suffix list from
http://ftp.penguin.cz/pub/users/utx/gnome-dcraw/dcraw.xml

'application/x-ufraw' is for ufraw ID files. An ID file contains data for
converting a specific raw image. 'ufraw IDFILE.ufraw' will convert the image
according to the data in the ID file. I'm not sure if this should have been
'application/x-ufraw' or 'image/x-ufraw'. Anyway, if you think it does not
belong in freedesktop.org I don't have a problem with that.

I made all the raw formats <sub-class-of type="image/x-dcraw"/>. This is then
used in the desktop file. For example in ufraw:

MimeType=application/x-ufraw;image/x-dcraw

This way there is no need to update the desktop file each time a new raw type is
supported. This could be used by any software based on dcraw, like ufraw,
digikam and dcraw itself. I didn't check if the 'image/x-dcraw' mime type itself
is necessary. It just seemed strange to have sub-class-of a type that is not
defined.

You might want to test how these mime types behave with UFRaw-0.10, which was
just release. Just don't forget to './configure --enable-mime' and read the
README. Thumbnail are generated in nautilus and double clicking opens the image
in ufraw.

Sample raw files (and a UFRaw ID file) can be found at:
http://ufraw.sourceforge.net/mime/
I'll probably remove this link in a few weeks so keep the copy you download.

Udi

About application/x-ufraw: I am not sure, what is the freedesktop.org consensus
for application-specific data files. But having it in freedesktop.org does not
allow future major format changes.

About image/x-dcraw: I understand your intention. But I think, that having a
MIME type for "all MIME types supported by application xxx" in freedesktop.org
is not the right way, becausev it makes assumption, that dcraw version >= foo is
installed altogether with this version of shared-mime-info.

"This way there is no need to update the desktop file each time a new raw type
is supported." Yes, it is true, but this way there is a need to update
freedesktop.org whenever dcraw will start to support new raw type.

This is exactly the purpose, for which I proposed "virtual MIME types", which
may appear in one of the next Shared MIME Info specifications, and will allow to
specify the list of MIME types actually supported by some subsystem. For my
original proposal, see
http://lists.freedesktop.org/archives/xdg/2005-November/007544.html (final
implementation may differ).

About application/x-ufraw: The basic format is xml with .ufraw file type. The
files starts with <UFRaw Version='7'>, where the version number can and will
change, but future versions of ufraw should be able to read files from older
versions. Is this format definition stable enough for freedesktop.org?

The only change that I think should be considered, before adding it, would be
whether it should be called 'application/x-ufraw' or 'image/x-ufraw'.

About image/x-dcraw: Instead of viewing it as 'all mime types supported by the
application dcraw', it should be considered as 'all know mime types for Digital
Camera RAW files'.

Notice that there is no correlation between the information in the mime type and
the list of raw formats supported by a specific version of dcraw or any other
software. For example, the Nikon D80 is supported only from dcraw 8.36, but its
mime type is image/x-nikon-nef, just like all Nikon digital cameras ever
manufactured.

> "This way there is no need to update the desktop file each time a new raw type
> is supported." Yes, it is true, but this way there is a need to update
> freedesktop.org whenever dcraw will start to support new raw type.

We need to update freedesktop.org when a camera manufacture comes out with a new
format. This is not different from the current implementation in
freedesktop.org. In any case this should not happen to often. I think that the
only new format from the last year is image/x-sony-arw.

It is good to know about "virtual MIME types". It could be very useful for the
ufraw-gimp plug-in. I don't see how it relates to the issue at hand (notice that
you yourself are using image/x-dcraw in the example).

application/x-ufraw: You do not include magic, so it's your (and freedesktop.org
maintainer's decision). Looking at application/* in freedesktop.org, many single
application specific formats are included, some are not. I guess that it can be
included, too.

image/x-dcraw: Yes, as 'all known mime types for Digital Camera RAW files' it is
acceptable. But in this case image/x-dcraw should cover other RAW file types
without dedicated MIME type:

    <glob pattern="*.bay" />
    <glob pattern="*.bmq" />
    <glob pattern="*.cs1" />
    <glob pattern="*.dc2" />
    <glob pattern="*.fff" />
    <glob pattern="*.k25" />
    <glob pattern="*.mos" />
    <glob pattern="*.pef" />
    <glob pattern="*.rdc" />
    <glob pattern="*.srf" />
    <glob pattern="*.x3f" />

Created attachment 7586 [details] [review]
shared-mime-info-raw.patch

Proposed patch based on your list with added suffixes to image/x-dcraw (list
from previous comment minus all raw MIME types handled specially).

Created attachment 7602 [details]
ufraw-mime.xml

You are missing erf, hdr, mdc, pxn and sti file types (list taken from Dave
Coffin's rawphoto.c).

For *.k25 I found a sample raw and it is also sub-class-of image/tiff. I added
it, but I'm not sure it is of much interest. This format was used in the Kodak
D25 camera that had resolution of 501 by 242. If freedesktop.org wants to
support all file format, it should be added. If there is screening for really
obscure file types it can be ignored.

*.hdr is used by Leaf Cameras and is a sub-class-of image/tiff. The link at
http://filext.com/detaillist.php?extdetail=hdr&Search=Search seems to indicate
that this definition is not unique so I'm not adding it at the moment.

There are 2 more raw file types *.jpg, *.tif. I think they are used by some old
Canon and Kodak cameras. For these two cases it is obvious that adding them
would cause more harm than good unless we have some very strong magic.

To summaries, we are missing the following types (in addition to the *.hdr,
*.jpg, *.tif discussed above):
    <glob pattern="*.bay" />
    <glob pattern="*.bmq" />
    <glob pattern="*.cs1" />
    <glob pattern="*.dc2" />
    <glob pattern="*.erf" />
    <glob pattern="*.fff" />
    <glob pattern="*.mdc" />
    <glob pattern="*.pxn" />
    <glob pattern="*.mos" />
    <glob pattern="*.rdc" />
    <glob pattern="*.sti" />
I'm guessing that they are all from outdated cameras. I suggest not adding them
to the mime database without magic. I'll try to find some samples from these
cameras. Meanwhile, it would be nice if what we have so far would be added to
shared-mime-info.

Attached is a new version of ufraw-mime.xml with the image/x-kodak-k25. I added
magic to image/x-fuji-raf, so now all the mime types are either sub-class-of
image/tiff or have magic. I also changed the priority of image/x-canon-crw from
60 to 50. It was 60 to override the old mime type in freedesktop.org, which is
no longer relevant.

Created attachment 7603 [details] [review]
/home/udif/sf/ufraw/shared-mime-info-ufraw.patch

Attached is a patch for shared-mime-info with the latest version of
ufraw-mime.xml.

Created attachment 8776 [details] [review]
shared-mime-info-ufraw.patch

Previous patch updated for shared-mime-info-0.20.

Can you apply it, please?

*** Bug 4117 has been marked as a duplicate of this bug. ***

I just did some cleaning on old patched.

Patch 8776 is safe to commit.

Thanks for your hard work! Committed, closing.