MIME types

radiance-dev
1

Apologies for the last copy-n-paste exercise. Here is a new thread...

Hi all,

worn out by the painstaking process of configuring default apps for
RADIANCE-specific files for LEARNIX in multiple desktop environments, I'm
contemplating submitting some new MIME types to
http://www.freedesktop.org,
to make this somewhat less painful next year. I'v no idea if this is used
at all on Mac OS, but on LINUX it seems to be the next BIG thing. It is
already used by XFCE4, although KDE (still?) seems to do it's own thing.

Since my last post regarding the configuration of web servers to put a
sensible MIME-type to HDR images didn't give any conclusions, I'm making
another attempt at this.

Basically, what it is is this: When an app is installed that can handle
certain file types, it updates the system's MIME configuration. In theory,
all desktop environment, file managers etc. should then be able to assign
the correct double-click action to those files.

The tutorial for submitting MIME types to freedesktop.org is here:
http://www.freedesktop.org/wiki/Standards_2fAddingMIMETutor

The issues are:

- I don't think there is any way of putting MIME magick into the plain
text files, e.g. .rad, .rif, .mat, .vf, but since they are opened in a
text editor, there is not much of a problem. Yes, different icons would be
nice, but then...

- What we CAN do is do this for the binary files, e.g. RADIANCE images,
octrees (holodeck?, meta data?)

- The MIME type can be determined by two means:

-- the first few bytes of a file. This is referred to as MIME magick. This
should be straight-forward for octrees and pics

-- file extensions
I won't attempt to work out a common file naming scheme for rad,rif,mat
etc, since they don't have any 'magick' in them, anyway. What I would like
to do is to just fire off ximage when a .pic file is double-clicked one.

So here is my question: What do you guys use as default file name
extensions in your RADIANCE projects? Those are my preferences:
.pic for synthetic RADIANCE RGBE images
.hdr for HDRs assembled from photos
.oct for octrees

BTW: I know this is a UNIX thing (we don't need no friggin' extensions)
but some of the file in the RADIANCE examples, e.g. the cabin scene, are
not gonna go through...

There might potentially a bit of confusion with the RADIANCE XYZE, which I
don't tend to use. I think that RBGE and XYZE should really have different
extensions. Do you think there is any way of having a 'RADIANCE standard'?

How about just going for .rgbe and .xyze? Dirty four-letter extensions are
no-longer a problem, it seems...

Please comment.

Cheers

Axel

PS: In the long run, it wouldn't hurt have a set of default extensions...

2

Hi,

  .hdr
  .pic
  .rgbe
  .xyze

That's a nice selection. For backward-compatibility I would prefer to keep
.pic for now. Many examples you find on the web use this extension.

Different color spaces in the same image type are quite common. TIFF
supports many different color spaces internally, and the files all
end in '.tif'. Again, the FORMAT= line in the Radiance header tells
you what data is enclosed. Since the byte appearance of the data is
identical between RGBE and XYZE, it doesn't warrant a different file
type, following other people's traditions.

All right. I wasn't quite sure. Thanks for this clarification.

I'd prefer it if we just stuck to one extension for Radiance images,
probably '.hdr' because of the problems with '.pic'. What is the
point of using two different extensions for the same format?
They're both images. Are we really going to associate different programs
with .pic and .hdr?

For some reason, I actually do: For synthetic .pic I use ximage, and for
assembled .hdr I tend to fire off the excellent pfsv from the pfstools,
with all the extra functionality. Having said that, I haven't included it
into LEARNIX (yet?)

There are actually two sides to the MIME coin:
1) Define what the files are
2) Configure default apps for 1)

Irrespective of the actual extension, with regards to RADIANCE we're
pretty clear as to what the 'double-click action' should be for an RGBE or
XYZE image file: ximage.

If I wanted to define a default app for an octree, what would be sensible
thing to do:
- rvu,
- a shell with getinfo
- nothing
- ???

Other then images and octrees, is there a file type that I've forgotten to
mention, one that has a bullet-proof definition thanks to some standard
file header? Like some holodeck stuff?

Finally, any thoughts on the actual TYPE I should define? This is the
biggest problem I'm facing. On the WebHDR server, I defined the HDR images
as image/x-radiance. Is this sensible? And what would an octree be?

Thanks for your feedback

Cheers

Axel

3

If I wanted to define a default app for an octree, what would be sensible
thing to do:
- rvu,
- a shell with getinfo
- nothing
- ???

I'd say "nothing". An octree is an internal file/format. Do people pass
around octree files?

Finally, any thoughts on the actual TYPE I should define? This is the
biggest problem I'm facing. On the WebHDR server, I defined the HDR
images as image/x-radiance. Is this sensible? And what would an octree
be?

hmmm, I'm guessing "application/x-radiance-octree".

I notice there's a model/* hierachy in my mime.types file, with types
defined for IGES, mesh (?), and VRML. Perhaps you can use
"model/x-radiance" for Radiance scene/object files?

What about the .rif files used by the rad frontend?
Perhaps "application/x-radiance-rif", and fire up "rad -o x11"?

Just some ideas,
bye

···

On Thu, 23 Nov 2006 11:35:02 -0000 (GMT) "Axel Jacobs" <[email protected]> wrote:

4

From: Ian Tester <[email protected]>
Date: November 23, 2006 3:59:18 AM PST

If I wanted to define a default app for an octree, what would be sensible
thing to do:
- rvu,
- a shell with getinfo
- nothing
- ???

I'd say "nothing". An octree is an internal file/format. Do people pass
around octree files?

Octrees are a compiled form of a Radiance scene, and may be used to convey geometry and materials in a self-contained form. As such, octrees (compiled iwth -f) frequently appear in Radiance object libraries. Running getinfo is a reasonable action. Rvu requires a default view, which isn't included in the octree. Starting rvu may be a sensible thing to do with a rad input file (i.e., run "rad -o x11 $inp").

Other then images and octrees, is there a file type that I've forgotten to
mention, one that has a bullet-proof definition thanks to some standard
file header? Like some holodeck stuff?

The holodeck files end in .hdk, but are not universally transportable, like the other binary files in Radiance.

We should have a MIME type for Radiance triangle meshes (.rtm) and we could include a type for ambient files (.amb), but here we really are getting very application-specific.

Finally, any thoughts on the actual TYPE I should define? This is the
biggest problem I'm facing. On the WebHDR server, I defined the HDR
images as image/x-radiance. Is this sensible? And what would an octree
be?

hmmm, I'm guessing "application/x-radiance-octree".

Sounds reasonable, but I don't know anything about MIME types. I recall that Peter A-B was one of the early adopters. We should also ask him.

-Greg

···

On Thu, 23 Nov 2006 11:35:02 -0000 (GMT) > "Axel Jacobs" <[email protected]> wrote:

5

Hi guys,

I've hit the first wall before I've even dug into the full subject. Greg,
maybe you can clarify:

Both, RGBE and XYZE come in flat and in RLE flavours. However, the
official file specs only mention two FORMAT= string, i.e. 32-bit_rle_rgbe
and 32-bit_rle_xyze. How does this work?

I recall that Peter A-B was one of the early adopters. We
should also ask him.

I've been in touch with him about rshow on LEARNIX. He appears to be
extremely busy

The MIME specs have the notion of subclasses. So would RGBE and XYZE be
subclasses of RADIANCE HDR?

"A type is a subclass of another type if any instance of the first type is
also an instance of the second. For example, all image/svg files are also
text/xml, text/plain and application/octet-stream files. Subclassing is
about the format, rather than the catagory of the data (for example, there
is no 'generic spreadsheet' class that all spreadsheets inherit from)."

They would both go into image/x-radiance

Finally, I have only glimpsed at the naming conventions, but as you say,
Ian, there are those model things:

model/radiance-material
model/radiance-geometry
model/radiance-view
model/radiance-triangle-mesh

Finally, octrees and ambient files.
They are not strictly speaking model types. Here is what we can pick from:

    application
    audio
    example
    image
    message
    model
    multipart
    text
    video

So we are probably stuck with 'model'.

The good news is that a MIME definition doesn't seem to require magic,
e.g. VRML is only defined by the glob:

  <mime-type type="model/vrml">
    <comment>VRML document</comment>
    <comment xml:lang="de">VRML-Dokument</comment>
    <glob pattern="*.wrl"/>
  </mime-type>

So there should be no problem with the old .rad, .mat, .vf
Those seem to be the more important ones. I won't get too carried away for
now (.cal .bgraph .norm etc)

Does any-one uses .sky for gensky generated output? I remember seeing this
somewhere a long time ago...

I'm leaving for London on Fri, and will be fairly busy. Thanks for your
input so far. It might be a few days before I can read up on the subject a
little bit more.

What I haven't worked out yet is why some types are x-soandso, other only
soandso. There are also alias and round robins. Oh, well...

Cheers

Axel

6

It's an old internet convention also used in email and HTTP headers (and
probably lots of other places). Anything prefixed with 'x-' is
non-standard. I guess it originally stood for 'experimental'. Just look at
the source of any of these emails and you'll see lots of headers starting
with 'x-'. They were added by the sender's email client and possibly
systems the email travelled through e.g your ISP might add spam-detection
headers. They're not part of the standard and can be almost anything.

In the MIME world it, types have to be officially approved. For example,
PNG originally used image/x-png before image/png was officially allocated.

bye

···

On Thu, 23 Nov 2006 22:22:45 -0000 (GMT) "Axel Jacobs" <[email protected]> wrote:

What I haven't worked out yet is why some types are x-soandso, other only
soandso. There are also alias and round robins. Oh, well...

7

Hi Axel,

From: "Axel Jacobs" <[email protected]>
Date: November 23, 2006 2:22:45 PM PST

I've hit the first wall before I've even dug into the full subject. Greg,
maybe you can clarify:

Both, RGBE and XYZE come in flat and in RLE flavours. However, the
official file specs only mention two FORMAT= string, i.e. 32-bit_rle_rgbe
and 32-bit_rle_xyze. How does this work?

I decided not to sub-type based on the presence or absence of run-length encoding. Since the reader routines identify RLE on a per scanline basis (and in fact there can be a mix of RLE and uncompressed scanlines), there seemed no need for a separate format specifier.

The MIME specs have the notion of subclasses. So would RGBE and XYZE be
subclasses of RADIANCE HDR?

Again, I wouldn't bother to distinguish these within MIME. It would be like distinguishing between different classes of TIFF. Any software that opens an RGBE file will also open an XYZE file, even if it won't display the colors correctly.

Finally, octrees and ambient files.
They are not strictly speaking model types. Here is what we can pick from:

    application
    audio
    example
    image
    message
    model
    multipart
    text
    video

So we are probably stuck with 'model'.

An octree is a compiled model, so nothing wrong with that designation.

So there should be no problem with the old .rad, .mat, .vf
Those seem to be the more important ones. I won't get too carried away for
now (.cal .bgraph .norm etc)

I'm not sure why we're classifying textfiles with MIME, but then, I don't understand the whole thing very well anyway. I would think .cal files to be more important (and more standard) than .vf files.

Does any-one uses .sky for gensky generated output? I remember seeing this
somewhere a long time ago...

I don't think this was ever used with any regularity. A gensky output is a .rad file.

-Greg