headers
Ken McGaugh | 6 Jun 06:48

Imf::Attribute compiler warning

I'm seeing the following compiler warning under linux with gcc-4.0.2  
when extra warnings are enabled (-Wextra):

     /usr/local/include/OpenEXR/ImfAttribute.h:256: warning: base  
class 'class Imf::Attribute' should be explicitly initialized in the  
copy constructor

The code which triggers this is:

     Imath::M44f mat;
     Imf::Header hdr (720, 486);
     hdr.insert("mat", Imf::M44fAttribute(mat));

The warning goes away if I use an intermediate Imf::M44fAttribute  
object:

     Imath::M44f mat;
     Imf::M44fAttribute matAttr (mat);
     Imf::Header hdr (720, 486);
     hdr.insert("mat", matAttr);

The warning seems benign, but I wanted to check to make sure.  Anybody  
know for sure?

Also, there is a typo in the commented example for ASSERT in  
IexMacros.h.  In the example the order of the arguments is listed  
incorrectly.

Thanks.
--Ken
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ger Hobbelt | 17 Jun 08:47
Favicon
Gravatar

typo/bug in exrmaketiled : makeTiled.cpp (+ diff / fix)

See diff below. Probably a typo or some such. Passes the tests at
least on Win32.

code diff'ed against today's anonymous CVS at savannah.

(FYI: the '[i_a]' tag in there is a marker I often use to tag changes
so I get a 'hint' when merging / reviewing code trees. Old habit...)

If this is not the place for bugreports of this nature, please point
me to the proper place. Thanks.

Ger

--- \\Debbie\ger\prj\1original\OpenEXR\src\OpenEXR\exrmaketiled\makeTiled.cpp	2006-06-05
04:04:52.000000000 +-0200
+++ \\Debbie\ger\prj\3actual\OpenEXR\OpenEXR\exrmaketiled\makeTiled.cpp	2008-06-17
06:42:04.000000000 +-0200
@@ -643,13 +643,13 @@
 		    if (verbose)
 			cout << "level (" << lx << ", " << ly << ")" << endl;

 		    storeLevel (out, header.channels(), lx, ly, *iptr0);
 		}
 		
-		if (lx < out.numXLevels() - 1);
+		if (lx < out.numXLevels() - 1)   /* [i_a] ??? */
 		{
 		    iptr1->resize (out.dataWindowForLevel (lx + 1, ly));

 		    reduceX (header.channels(),
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ger Hobbelt | 17 Jun 09:06
Favicon
Gravatar

buf + fix for CreateDLL tool on Windows

Very nice idea, this CreateDLL, by the way. :-) (comes in handy for a
few other DLL/C++ issues here. Dang. Why didn't I think of this?)

Anyway, what happens is that CreateDLL scans the map file for exports,
object files and DLLs in that order.
By the time the code has arrived at the spot where it's looking for
the DLL dependencies to tell 'link.exe' which matching '.lib's to
load, the scan is prematurely aborted as the 'object file scan'
corrupted the mapfile in memory (stored in buf; 'lineend' is the
offending pointer though).

This happens, because where it says:

-                    *lineend = '\0';

to replace an EOL by a NUL sentinel for the next of work, the code
assumes this 'lineend' pointer does NOT change until this line:

-                    *lineend = '\n';

where the EOL is restored.

Alas, this assumption is not true, as there's this bit of code:

                             if (accept) {
                                 lineend = lineend - 6;  // point one
character before ".dll"
                                 while (!isWhitespace(*lineend))
                                 {
                                     --lineend;
(Continue reading)

Permalink | Reply | 0 comments |
headers
Florian Kainz | 18 Jun 19:40

Re: RAW images in OpenEXR?

Alexander Forsythe wrote:
> Florian, 
> B44 and B44A are wonderful algorithms for traditional uses of OpenEXR, 
> but you correctly pointed out that Lossy compression methods (B44, B44A) 
> would introduce crosstalk between the channels.  This is 
> highly undesirable and exactly what the Red camera folks are now taking 
> a lot of heat for.  I'd suggest limiting compression to lossless 
> compression methods for RAW data storage. 

Hi Alex,

the proposed RAW storage format eliminates crosstalk between channels.
The channels are compressed individually, and no information leaks from
one channel into another.

Artifacts caused by lossy compression still introduce color and
luminance noise, just as with RGB or luminance/chroma images.  Sharpening 
peformed during conversion to RGB may amplifiy noise in luminance/chroma
images.  So far we haven't done any tests to determine which compression
methods would work well for RAW images.

Florian
Permalink | Reply | 0 comments |
headers
Florian Kainz | 18 Jun 20:24

Re: RAW images in OpenEXR?

In the proposed format the raw image is split into channels, one
per filter color.  The individual channels are not fully populated;
for example, with an RGB Bayer-pattern CFA, only half of the pixels
in the green channel, and a quarter of the pixels in the red and
blue channels have data.  My original email describes how this can
be stored efficiently in an OpenEXR file.

As I mentioned earlier, I have not done enough testing to know how
algorithms such as B44 affect RAW images.  On the other hand, looking
closely at the RAW images output by some cameras, I suspect that the
files have been compressed with a lossy method (or maybe the camera
sensors produce rather peculiar block-like artifacts).

Alexander Forsythe wrote:
> Thanks Florian
> 
> That's good news that the channels are compressed individually.
> How exactly what this achieved given there's essentially only 
> one channel in a RAW image?
> Regardless, it's always been my impression that lossy compression, via 
> either a lossy compression algorithm or quantization, of RAW images is 
> frowned upon, but maybe options are good ... Just my 2ยข
> 
> Alex
> 
> ______________________________________
> Alexander Forsythe
> Senior Imaging Engineer
> Academy of Motion Picture Arts and Sciences
> Science and Technology Council
(Continue reading)

Permalink | Reply | 0 comments |
headers
Chris Cox | 18 Jun 21:14
Picon
Favicon

RE: RAW images in OpenEXR?

Alex;

In all testing so far, interpolating the matrices has given very, very good results.
You can ask for more details on the DNG/ACR user forums.

Common light sources don't have that wide a variety of spectra.  Cheap fluorescent lamps and sodium lamps
are the exceptions (and difficult to correct for anyway).

No, nothing about the file format or the calibrations dictates how subsequent image processing occurs,
nor does anything else about the file format.

DNG is already in widespread use, with very few complaints about the format (although there have been a few misunderstandings).

Chris

-----Original Message-----
From: Alexander Forsythe [mailto:alexforsythe <at> gmail.com]
Sent: Wed 6/18/2008 9:22 AM
To: Chris Cox; Florian Kainz; openexr-devel <at> nongnu.org
Subject: Re: [Openexr-devel] RAW images in OpenEXR?

Chris,

One issue with DNG I've always had is the storage and usage of Camera  
RGB to XYZ  matrices.
Correct me if I'm wrong, but DNG only allows for the storage of two  
RGB to XYX matrices and it's suggested that they be built using  
sources with the chromaticities of D65 and A.
I could see many situations where it'd be highly preferable to store  
more than two RGB to XYZ matrices in metadata.  The proposed OpenEXR
(Continue reading)

Permalink | Reply | 6 comments |
headers
Alex Forsythe | 18 Jun 22:15
Favicon

RE: RAW images in OpenEXR?

Chris,
I don't want to get too off the EXR topic here ...  
I'll just say, I admit that I have not done any testing using the adobe approach, but I just strikes me as an
issue that opens the door to debate.
Is there a metadata tag that would be appropriate for storage of RGB to XYZ matrices for additional
illuminants in order to avoid the issue?
Alex

_____________________________________________

Alexander Forsythe
Senior Imaging Engineer
Academy of Motion Picture Arts and Sciences

Address: 1313 Vine Street
              Hollywood, CA 90028
Phone:    310-247-3000 x310
Fax:        310-247-3611

>>> "Chris Cox" <ccox <at> adobe.com> 6/18/2008 12:14 PM >>>
Alex;

In all testing so far, interpolating the matrices has given very, very good results.
You can ask for more details on the DNG/ACR user forums.

Common light sources don't have that wide a variety of spectra.  Cheap fluorescent lamps and sodium lamps
are the exceptions (and difficult to correct for anyway).

No, nothing about the file format or the calibrations dictates how subsequent image processing occurs,
nor does anything else about the file format.
(Continue reading)

Permalink | Reply | 5 comments |
headers
Chris Cox | 18 Jun 22:32
Picon
Favicon

RE: RAW images in OpenEXR?

Alex;

I'm not sure on that point - I haven't kept up with all the latest DNG changes.
I know they were considering a more flexible calibration system, but I don't know what they settled on (or if
it is completely settled).
However, DNG is headed for ISO standardization, so they may be nailing everything down soon.

Chris

-----Original Message-----
From: Alex Forsythe [mailto:aforsythe <at> oscars.org]
Sent: Wed 6/18/2008 1:15 PM
To: Chris Cox; Florian Kainz; openexr-devel <at> nongnu.org
Subject: RE: [Openexr-devel] RAW images in OpenEXR?

Chris,
I don't want to get too off the EXR topic here ...  
I'll just say, I admit that I have not done any testing using the adobe approach, but I just strikes me as an
issue that opens the door to debate.
Is there a metadata tag that would be appropriate for storage of RGB to XYZ matrices for additional
illuminants in order to avoid the issue?
Alex

_____________________________________________

Alexander Forsythe
Senior Imaging Engineer
Academy of Motion Picture Arts and Sciences

Address: 1313 Vine Street
(Continue reading)

Permalink | Reply | 0 comments |
headers
Lars Borg | 18 Jun 22:34
Picon
Favicon

RE: RAW images in OpenEXR?

Alex,

Why store additional illuminants in the DNG or RAW file? It should 
suffice to have these in the camera.

If you know the illuminant used at time of capture exactly, you need 
only one matrix, not two.
If you know it only approximately, say daylight versus tungsten 
versus flourescent, you may want two matrices, to span the category.
Embedding say 20 matrices in the DNG file, one for every candidate 
illuminant, is not going to help you, as most won't be applicable to 
the particular image.
I think it's a reasonable assumption that the camera can discriminate 
between tungsten and daylight.

Lars

At 1:15 PM -0700 6/18/08, Alex Forsythe wrote:
>Chris,
>I don't want to get too off the EXR topic here ... 
>I'll just say, I admit that I have not done any testing using the 
>adobe approach, but I just strikes me as an issue that opens the 
>door to debate.
>Is there a metadata tag that would be appropriate for storage of RGB 
>to XYZ matrices for additional illuminants in order to avoid the 
>issue?
>Alex
>
>
>_____________________________________________
(Continue reading)

Permalink | Reply | 3 comments |
headers
Alex Forsythe | 18 Jun 23:14
Favicon

RE: RAW images in OpenEXR?

Lars,

"It should suffice to have these in the camera."

The matrices aren't applied in the camera though because it's RAW data.

"If you know the illuminant used at time of capture exactly, you need 
only one matrix, not two."

True, but you don't know the illuminant at time of capture.  You may be able to deduce it from other camera
setting like white balance, or gamut of reproduced colors, and embed the single correct matrix in the DNG
file. However, if the illuminant estimation algorithm missed you don't have access to the other
precalculated RGB to XYZ matrices for that camera when you go and process that raw file.  It just seems like
it'd be a lot simpler to embed a few extra matrices and call it a day. 

"I think it's a reasonable assumption that the camera can discriminate 
between tungsten and daylight."

I'd suggest that it's not unreasonable that a professional camera discriminate between 2 or 3 color
temperature daylight sources, 1 or 2 types of flourescent, tungsten, flash, and maybe even something
like sodium vapor.  Again, I wouldn't be concerned that all of the matrices actually get embedded in the DNG
file if a reasonable illuminate estimation algorithm is used at time of capture, but they all need to be
precalculated and stored somewhere.  Currently, DNG only precalculates 2 matrices and then
interpolates the matrix coefficients for the estimated illuminant from the matrix coefficients for
those 2 precanned matrices even though the SPD's used to build those 2 matrices were very different from
each other, and potentially very different from the actual source used to illuminate the scene.

Alex

_____________________________________________
(Continue reading)

Permalink | Reply | 2 comments |

Gmane