openexr-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Openexr-devel] More examples


From: Richard Annema
Subject: Re: [Openexr-devel] More examples
Date: Sat, 17 Jan 2004 06:03:39 +0100

Hi Brad,

Technically, if you can read/write OpenEXR according to spec, then writing
'compatible' files shouldn't be an issue at all, let alone reading existing
files.

The only thing that could differ is the datatypes used, what the data
represents, and how that data is indicated. And there I think, rather than
having multiple implementations and having software recognize which
implementation is being used and work accordingly, standardization is an
effort that should be undertaken.

I've put a zip file with some simple sample files ( based on a test scene
for
3ds max's g-buffers, expect nothing pretty ;) ) available, but for those who
would download it I'll say now (and will again at the actual post, if I
don't forget) that the channel types/names/etc. written by our plugin are in
no way meant to be guides for other implementations. Any such guides should
come from cooperation between developers and users in much the same way the
new fields specified in OpenEXR 1.0.7 came to fruition.

The zip can be downloaded from :
http://www.pointzero.nl/sf/splutterfish_openexr_plugin_samples.zip
It also includes an overview of the files and the PackedIntRGBa structure in
an .html file.

If there's any specific requests, just let me know.

Best,
Richard Annema

----- Original Message ----- 
From: "Brad Hards" <address@hidden>
To: <address@hidden>
Cc: "Richard Annema" <address@hidden>
Sent: Friday, January 16, 2004 13:53
Subject: Re: [Openexr-devel] More examples


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Fri, 16 Jan 2004 18:30 pm, Richard Annema wrote:
> Hi Brad,
>
> And if you need any from 'the wild' ( in addition to Drew's suggestion ),
I
> can easily get you some images with all the compressions types, bitdepths,
> custom channels/fields and datatypes from our plugin today.
I certainly see having a range of images (which potentially exercise
different
code paths, rather than just showing different scenes) is useful for doing
verification of new functionality, and also for performing regression
testing.

It would be good if we can make a "representative sample" of images from
each
plugin/tool available for interoperability testing too.

I'd personally appreciate seeing whatever you can make available.

Brad
- -- 
http://linux.conf.au - Having fun now!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQFAB97WGwwszQ/PZzgRAspRAKCgcafyTbKyQvdzxp8D1l7lPt7xOgCePbUB
bZxnup8PQ5nn4frJydga/TU=
=Vwcs
-----END PGP SIGNATURE-----





reply via email to

[Prev in Thread] Current Thread [Next in Thread]