exrdisplay error when reading deepscanline

[academysoftwarefoundation]

exrdisplay error when reading deepscanline

[fnordware]

Another thing: when using the commit that makes a functioning exrdisplay, deeptile files look different from deepscanline. For example, these files should look the same:

http://www.fnordware.com/downloads/deep_test.exr
http://www.fnordware.com/downloads/deeptile_test.exr

Brendan

[peterhillman]

Apologies for the late reply.
That file appears to be corrupt: the file flags indicate that the
image is a regular image, not a deep image, but the data itself
appears to be written as a deep image. Perhaps you didn't explicitly
set the type of the file to 'deepscanline' before writing. The
latest EXR library will silently fix this for you and ensure the
file flags are written correctly.On 26/07/13 10:10, Brendan Bolles
  wrote:

  I wrote this deepscanline file using the latest commit (34f5447) from the master
    branch:
  http://www.fnordware.com/downloads/deep_test.exr
  If build exrdisplay from HEAD (34f5447) and try to preview
    it I get an error: "Unexpected data block y coordinate". An
    older commit I'm using (e941cc4) doesn't have this
    problem.
  —
    Reply to this email directly or view it on
      GitHub.

[fnordware]

I am using the most recent commit from the master branch, which sets the type for you when you use DeepScanLineOutputFile or any other *OutputFile. Moreover, if I run exrheader, the files show the correct type.

[peterhillman]

If I run exrheader from the most recent commit, it shows the type being
scanlineimage, since the "nonimage" bit isn't set in the flags field.
(Deep images should have flags 0x800, your image has flags 0x0)

The following code run with an old version of the library creates a file
with the wrong flags, but with the current HEAD creates the file
correctly. I suspect that's the problem you have.

{
Header h;
h.compression()=ZIPS_COMPRESSION;
DeepScanLineOutputFile fred("test.exr",h);
}

It is necessary that the flags take precedence over the type attribute
when they conflict, since it it possible to read an image with an
EXR-2.0.X library and write it with the EXR-1.7.X library. The older
library will write the correct flags but not the correct type attribute.
The new release enforces this precedence.

[fnordware]

As far as I can tell, I'm using the current HEAD. We're talking about the master branch, right?

I think I figured out the problem. In this version of the DeepScanLineOutputFile constructor:

DeepScanLineOutputFile::DeepScanLineOutputFile
(OPENEXR_IMF_INTERNAL_NAMESPACE::OStream &os,
const Header &header,
int numThreads)

writeMagicNumberAndVersionField is passed header instead of _data->header. Ditto for DeepTiledOutputFile. This gets confusing because header is passed to initialize(), but then that function sets the type for _data->header. Anyway, I changed header to _data->header in the constructor and it seems to work now on my machine.

So I'm seeing this bug because I'm using the OStream version instead of the const char * version.

It also looks like the logic in GenericOutputFile::writeMagicNumberAndVersionField() will set the deep flag (NON_IMAGE_FLAG) or the tiled flag (TILED_FLAG), but not both (as you might for deeptiled). Is that intentional?

[pstanczyk]

Taking a look - but the develop branch is the most up to date stable branch. The master branch typically points to the current released version.
Feature branches are off the develop branch.

• Piotr

  ---

  From: Brendan Bolles [[email protected]]
  Sent: 16 August 2013 07:34
  To: openexr/openexr
  Subject: Re: [openexr] exrdisplay error when reading deepscanline (#68)

As far as I can tell, I'm using the current HEAD. We're talking about the master branch, right?

I think I figured out the problem. In this version of the DeepScanLineOutputFile constructor:

DeepScanLineOutputFile::DeepScanLineOutputFile
(OPENEXR_IMF_INTERNAL_NAMESPACE::OStream &os,
const Header &header,
int numThreads)

writeMagicNumberAndVersionField is passed header instead of _data->header. Ditto for DeepTiledOutputFile. This gets confusing because header is passed to initialize(), but then that function sets the type for _data->header. Anyway, I changed header to _data->header in the constructor and it seems to work now on my machine.

So I'm seeing this bug because I'm using the OStream version instead of the const char * version.

It also looks like the logic in GenericOutputFile::writeMagicNumberAndVersionField() will set the deep flag (NON_IMAGE_FLAG) or the tiled flag (TILED_FLAG), but not both (as you might for deeptiled). Is that intentional?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-22769390.

[fnordware]

I submitted a pull request with the fix for the constructors. So files are written properly and exrdisplay does not complain.

I still have the problem with exrdisplay - it seems to show deeptiled files incorrectly. As mentioned before, I believe these two files should appear identical in exrdisplay, but they don't:

http://www.fnordware.com/downloads/deep_test.exr
http://www.fnordware.com/downloads/deeptile_test.exr

[pstanczyk]

Brendan,

Indeed, the deep tiled output looks a little odd. Let me take a closer look at what is happening here ...

• Piotr

  ---

  From: Brendan Bolles [[email protected]]
  Sent: 02 September 2013 16:25
  To: openexr/openexr
  Cc: Piotr Stanczyk
  Subject: Re: [openexr] exrdisplay error when reading deepscanline (#68)

I submitted a pull requesthttps://github.com//pull/72 with the fix for the constructors. So files are written properly and exrdisplay does not complain.

I still have the problem with exrdisplay - it seems to show deeptiled files incorrectly. As mentioned before, I believe these two files should appear identical in exrdisplay, but they don't:

http://www.fnordware.com/downloads/deep_test.exr
http://www.fnordware.com/downloads/deeptile_test.exr

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/68#issuecomment-23682931.

[fnordware]

exrdisplay fixes (or at least workarounds) in commit e3dc410, merged into develop branch with f359a02.

Thanks, Piotr!