RAW images in OpenEXR?

Recently several people have asked whether OpenEXR would be suitable
for storing RAW images from cameras with color filter array sensors.
The proposal below describes a method to do that.  I would be interested
in feedback from OpenEXR users.

Florian

OpenEXR RAW Images
------------------

CFA Image Sensors And RAW Images

     Digital image file formats such as OpenEXR or JPEG usually represent
     images as red-green-blue (RGB) data.  Conceptually, each pixel in an
     image file has a red, a green and a blue value.  Image files may be
     compressed, and compression often involves transforming the RGB
     pixels to an alternate format before the data are stored in a file,
     but the original RGB data can be recovered from the file - at least
     approximately - by reversing this transformation.

     The image sensors in most modern electronic cameras do not record
     full RGB data for every pixel.  Cameras typically use sensors that
     are equipped with color filter arrays.  Each pixel in such a sensor
     is covered with a red, green or blue color filter.  The filters are
     arranged in a regular pattern, for example, like this:

         G R G R G R
         B G B G B G
         G R G R G R

Re: RAW images in OpenEXR?

Hi Greg,

as I noted in my original mail, I wrote this proposal in
response to people asking me whether it would be feasible
to store RAW images in OpenEXR files.

Properly implemented, an "EXR RAW" format has the potential
to integrate nicely into existing OpenEXR-based work flows.
The RAW format could be combined with existing features,
such as the Weta multi-view format.

A RAW format with an open-source implementation would be
easier to support in new and existing application software
than one for which a file I/O library must be written from
scratch according to a lengthy specification.

I do realize that CFA-to-RGB demosaicing is not trivial, but
the task is no easier or harder with EXR RAW than with any
other format.  If you want to work with RAW files, then you
must have a way to convert to RGB.  You'll have to write or
license a converter.

Florian

Greg Ward wrote:
> Hi Florian,
> 
> You seem to have put a lot of thought into this.  Can you give a  little 
> background motivation for why incorporating RAW data into  OpenEXR is 
> desirable?  What are the advantages/disadvantages relative  to Adobe's 

RE: RAW images in OpenEXR?

Why would you want something un-EXR like in EXR?

Why not use existing open standards for camera RAW images?

See http://www.adobe.com/products/dng/index.html
and http://www.adobe.com/support/downloads/dng/dng_sdk.html

Chris

-----Original Message-----
From: openexr-devel-bounces+ccox=adobe.com <at> nongnu.org on behalf of Florian Kainz
Sent: Tue 5/6/2008 1:19 PM
To: openexr-devel <at> nongnu.org
Subject: [Openexr-devel] RAW images in OpenEXR?

Recently several people have asked whether OpenEXR would be suitable
for storing RAW images from cameras with color filter array sensors.
The proposal below describes a method to do that.  I would be interested
in feedback from OpenEXR users.

Florian

OpenEXR RAW Images
------------------

CFA Image Sensors And RAW Images

     Digital image file formats such as OpenEXR or JPEG usually represent
     images as red-green-blue (RGB) data.  Conceptually, each pixel in an
     image file has a red, a green and a blue value.  Image files may be

RE: RAW images in OpenEXR?

On Tue, 6 May 2008, Chris Cox wrote:

> Why would you want something un-EXR like in EXR?

Because they are not EXR? 

> Why not use existing open standards for camera RAW images?
>
> See http://www.adobe.com/products/dng/index.html
> and http://www.adobe.com/support/downloads/dng/dng_sdk.html

While DNG itself seems fine, I discovered a bug related to the Adobe 
DNG Software Development Kit (SDK).  The download link for free 
unencumbered portable open source does not appear to be working at the 
moment.

The common theme with RAW images seems to be abject horror that 
sometime in the distant future, someone will invent an algorithm which 
is able extract an extra 10 parts per million of image quality from 
today's RAW image files, thereby completely invalidating already 
translated files.  As a result, it is necessary to keep the RAW data 
available for the rest of time in case such an algorithm is invented. 
Without this fear, people would simply use the best quality existing 
software (e.g. 'dcraw') to convert to excellent-quality 16-bits/sample 
lossless TIFF files and delete the original Bayer data.

Bob
======================================
Bob Friesenhahn
bfriesen <at> simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/

Silhouette v3 released today with stereo OpenEXR support

Hey guys,

Just wanted to mention we've released version 3 of Silhouette, which has 
an entirely stereoscopic work-flow for 2D keying, roto, paint, and 
shape-based effects. There is full support for multi-view exr/sxr files, 
and there are 64 bit Linux and Windows versions available.

I'd like to thank everyone who helped me with EXR technical issues.

Cheers,
-Paul

--

-- 
Paul Miller | paul <at> fxtech.com | www.fxtech.com | Got Tivo?

Hither and Yon in Imath::Frustum

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel

Re: Hither and Yon in Imath::Frustum

This change would affect all existing software that
uses Imath::Frustum, including ILM's internal code...

Dan Wexler wrote:
> Greetings from a new mailing list subscriber, but long time library user,
>  
> The ImathFrustum.h header does a #undef on the "near" and "far" 
> abominations in the windows.h headers.  The implication is that you must 
> include ImathFrustum.h after including any Windows DX headers.  Yes, 
> Windows sucks, but the current #undef solution is not great either.
>  
> Why not use hither/yon instead of near/far in ImathFrustum.h and in the 
> associated code files?
>  
> Not only does this fix the problem elegantly, but it makes searching the 
> code easier, since hither/yon are more unique than near/far.  I'd be 
> willing to make and test out this change if folks agree that it is 
> worthwhile.
>  
>  
> Dan Wexler
>  
> ------------------------------------------------------------------------
> This email message is for the sole use of the intended recipient(s) and 
> may contain confidential information.  Any unauthorized review, use, 
> disclosure or distribution is prohibited.  If you are not the intended 
> recipient, please contact the sender by reply email and destroy all 
> copies of the original message.
> ------------------------------------------------------------------------
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Openexr-devel mailing list
> Openexr-devel <at> nongnu.org
> http://lists.nongnu.org/mailman/listinfo/openexr-devel

Added support for long channel names

Support for OpenEXR attribute and channel names with up to 255
characters has been checked into CVS.

Older versions of the IlmImf library (OpenEXR 1.6.1 and earlier)
only support names up to 31 characters.  Those versions of the
library will be able to read files written by the latest version
as long as the files do not contain names with 32 or more characters.

Florian

RE: Hither and Yon in Imath::Frustum

I agree that it would be improper to break the API before a major number
version change to IlmBase.  Is there an active 2.x branch?

One alternative is to redefine near and far at the bottom of this file,
and provide analogous Frustum::hither() and Frustum::yon() functions.
This fixes the include ordering problem and allows windows (and other)
developers to migrate their code before the 2.x API change.

I've attached a version of ImathFrustum.h with this change with these
changes that fix the include ordering and provide alternative hither/yon
functions.  I did a bit of searching through the windows headers and it
really does seem like windef.h simply defines near and far as empty, but
I'm not 100% confident of that change even though my app works (only
basic testing so far).

If we get really tricky, we can mark the Frustum::near() and
Frustum::far() functions as deprecated to generate a compiler warning,
which makes it easy to change your code without breaking anything in the
near term.  I'm not positive how to make that work since these are
inlined functions (Visual Studio has a #pragma deprecated, but I
couldn't get it to work in this case).

IMHO, this change is worthwhile in the long run.  It broadens the
potential user base significantly.  For example, if we ever wanted to
propose various portions of OpenEXR for inclusion with boost, or
eventually a future C++ standard, we would need to fix this near/far
issue.

> -----Original Message-----
> From: Florian Kainz [mailto:kainz <at> ilm.com]
> Sent: Wednesday, May 28, 2008 2:24 PM
> To: Dan Wexler
> Cc: openexr-devel <at> nongnu.org
> Subject: Re: [Openexr-devel] Hither and Yon in Imath::Frustum
> 
> This change would affect all existing software that
> uses Imath::Frustum, including ILM's internal code...
> 
> Dan Wexler wrote:
> > Greetings from a new mailing list subscriber, but long time library
> user,
> >
> > The ImathFrustum.h header does a #undef on the "near" and "far"
> > abominations in the windows.h headers.  The implication is that you
> must
> > include ImathFrustum.h after including any Windows DX headers.  Yes,
> > Windows sucks, but the current #undef solution is not great either.
> >
> > Why not use hither/yon instead of near/far in ImathFrustum.h and in
> the
> > associated code files?
> >
> > Not only does this fix the problem elegantly, but it makes searching
> the
> > code easier, since hither/yon are more unique than near/far.  I'd be
> > willing to make and test out this change if folks agree that it is
> > worthwhile.
> >
> >
> > Dan Wexler
> >
> >
---------------------------------------------------------------------
> ---
> > This email message is for the sole use of the intended recipient(s)
> and
> > may contain confidential information.  Any unauthorized review, use,
> > disclosure or distribution is prohibited.  If you are not the
> intended
> > recipient, please contact the sender by reply email and destroy all
> > copies of the original message.
> >
---------------------------------------------------------------------
> ---
> >
> >
> >
---------------------------------------------------------------------
> ---
> >
> > _______________________________________________
> > Openexr-devel mailing list
> > Openexr-devel <at> nongnu.org
> > http://lists.nongnu.org/mailman/listinfo/openexr-devel

_______________________________________________
Openexr-devel mailing list
Openexr-devel <at> nongnu.org
http://lists.nongnu.org/mailman/listinfo/openexr-devel