EXR embedded preview

[blue-j]

I've been trying to extract embedded previews in EXR files without joy.  Has anyone had success?

I've been working with the test images provided by OpenEXR:
https://openexr.com/en/latest/_test_images/index.html#test-images

This one specifically, which ExifTool reports as having a binary preview:
https://openexr.com/en/latest/_test_images/Tiles/GoldenGate.html

(I have tested with others as well.)  I get an export, but it is not a valid image type of any sort.

- J

 

[StarGeek]

Hmmm... Exiftool says the Preview contains 27,208 bytes, but the extracted data is only 69 bytes long.  And there are a lot of NUL characters.  But looking at the Preview with -v4 doesn't show hardly any NULs.  Though I don't know how it is actually encoded, as every fourth byte is 0x7f, which lead me to StackOverflow question.

In other words, I don't have a clue

[greybeard]

Hmmm... Exiftool says the Preview contains 27,208 bytes, but the extracted data is only 69 bytes long.  And there are a lot of NUL characters.  But looking at the Preview with -v4 doesn't show hardly any NULs.  Though I don't know how it is actually encoded, as every fourth byte is 0x7f, which lead me to StackOverflow question.

In other words, I don't have a clue

I think the 7F is just part of the floating point numbers that describe the preview image

[blue-j]

This is the source code, FWIW:

https://github.com/AcademySoftwareFoundation/openexr/blob/main/src/bin/exrmakepreview/makePreview.cpp

GPT-4 says this:

"The preview image in an OpenEXR file, as created by the code snippet you've provided, is indeed a binary object, but it's not stored in a standalone file format like JPEG or PNG. Instead, it's embedded directly within the OpenEXR file as a part of the file's header. The preview image is an array of binary data that represents a simple, low-resolution version of the main image, intended to be used as a thumbnail or a quick preview.

Each pixel in this preview is represented by the PreviewRgba structure, which suggests that each pixel is stored as a sequence of four bytes, corresponding to the red, green, blue, and alpha (transparency) channels of the image. This format is quite straightforward and does not adhere to any external or complex file format specifications. Instead, it is a simple, uncompressed, straight-to-the-point representation of pixel data designed for ease of access and minimal processing.

The key characteristics of the binary preview image in OpenEXR can be summarized as follows:

Embedded Directly in EXR File: The preview image is stored within the EXR file's header, not as a separate file.

Simple Binary Format: Each pixel is encoded in a basic RGBA format, with each channel typically represented by one byte.

No External Format Adherence: The preview does not conform to standalone image file formats like JPEG or PNG. It is designed to be a part of the EXR file structure.

Purpose: The primary purpose of this preview image is to provide a quick and easily accessible visual representation of the content, useful for viewing in file browsers or editing software that can parse EXR headers.

To extract and use this preview, one would need to read the EXR file's header, identify the preview image section, and then decode the binary data according to the RGBA byte structure. This process would not require interpreting the data according to external image format specifications but would require an understanding of the EXR file format and the specific structure of the preview image data as defined by the OpenEXR specifications."

So a preview is not formatted, but instead raw gamma-corrected RGBA values, if it's correct.

- J

[blue-j]

The fact that "every fourth byte is 0x7f" indicates that the image has a universal transparency set to 127 or 50% opaque possibly, if it is in RGBA?  Is that true?  127 is perfectly in the middle, which is curious.

- J

[blue-j]

It appears my prior links to test images no longer works?  Here they are in the source code:

https://github.com/AcademySoftwareFoundation/openexr-images

- J

[Phil Harvey]

Thanks for the sample.  I'll fix ExifTool 12.80 so the binary data is extracted properly as is.

- Phil

[blue-j]

Thanks, Phil!  I did test with test image Spirals.exr and didn't what I expected, but this format is utterly batshit flexible.  It is breaking my mind.

I have labeled the binary as .raw, and assigned dimensions of 100x (default X for EXR previews) and it does not result in clear output, more like a misshapen beastie against transparency.  have you tested with a few other samples?  which one did it work on for you?

I am studying its metadata / attributes and gobsmacked (have to borrow that word from the Brits for this!).

it seems that the metadata is broken into structs per part.  here's an example from composited.exr (attached - also at the same URL as what I shared before):

exrinfo -a composited.exr
File '/Users/jharmon/Documents/Downloads/EXR Samples/composited.exr': ver 2 flags longnames multipart
parts: 4
part 1: rgba.left
  channels: chlist 4 channels
  'A': half samp 1 1
  'B': half samp 1 1
  'G': half samp 1 1
  'R': half samp 1 1
  chunkCount: int 1078
  compression: compression 'zips' (0x02)
  dataWindow: box2i [ 1, 1 - 1918 1078 ] 1918 x 1078
  displayWindow: box2i [ 0, 0 - 1919 1079 ] 1920 x 1080
  lineOrder: lineOrder 0 (increasing)
  name: string 'rgba.left'
  nuke/node_hash: string 'b4ea9f917764b762'
  owner: string 'Copyright 2012 Weta Digital Ltd'
  pixelAspectRatio: float 1
  screenWindowCenter: v2f [ 0, 0 ]
  screenWindowWidth: float 1
  type: string 'scanlineimage'
  view: string 'left'
part 2: depth.left
  channels: chlist 1 channels
  'Z': half samp 1 1
  chunkCount: int 1078
  compression: compression 'zips' (0x02)
  dataWindow: box2i [ 1, 1 - 1918 1078 ] 1918 x 1078
  displayWindow: box2i [ 0, 0 - 1919 1079 ] 1920 x 1080
  lineOrder: lineOrder 0 (increasing)
  name: string 'depth.left'
  owner: string 'Copyright 2012 Weta Digital Ltd'
  pixelAspectRatio: float 1
  screenWindowCenter: v2f [ 0, 0 ]
  screenWindowWidth: float 1
  type: string 'scanlineimage'
  view: string 'left'
part 3: rgba.right
  channels: chlist 4 channels
  'A': half samp 1 1
  'B': half samp 1 1
  'G': half samp 1 1
  'R': half samp 1 1
  chunkCount: int 1078
  compression: compression 'zips' (0x02)
  dataWindow: box2i [ 1, 1 - 1918 1078 ] 1918 x 1078
  displayWindow: box2i [ 0, 0 - 1919 1079 ] 1920 x 1080
  lineOrder: lineOrder 0 (increasing)
  name: string 'rgba.right'
  owner: string 'Copyright 2012 Weta Digital Ltd'
  pixelAspectRatio: float 1
  screenWindowCenter: v2f [ 0, 0 ]
  screenWindowWidth: float 1
  type: string 'scanlineimage'
  view: string 'right'
part 4: depth.right
  channels: chlist 1 channels
  'Z': half samp 1 1
  chunkCount: int 1078
  compression: compression 'zips' (0x02)
  dataWindow: box2i [ 1, 1 - 1918 1078 ] 1918 x 1078
  displayWindow: box2i [ 0, 0 - 1919 1079 ] 1920 x 1080
  lineOrder: lineOrder 0 (increasing)
  name: string 'depth.right'
  owner: string 'Copyright 2012 Weta Digital Ltd'
  pixelAspectRatio: float 1
  screenWindowCenter: v2f [ 0, 0 ]
  screenWindowWidth: float 1
  type: string 'scanlineimage'
  view: string 'right'


i used exrinfo with the "all" -a switch, a utility included in the OpenEXR package. I'm looking at various ways of cracking the metadata open - we may just use exrinfo and format the output.  are you interested in supporting the format further in ET?

- J

[blue-j]

Minor:

OpenEXR:TimeZone

should be

OpenEXR:UTCOffset

Offset ≠ Time Zone

[Phil Harvey]

What is the difference?

My time zone is currently -04:00, and the offset from UTC is -4 hours.  Are there cases where this is different?  I thought this was the definition of the time zone.

- Phil

[blue-j]

it's a very common misunderstanding, one that i myself had until a month or so ago.  i have been almost solely studying datetime representation for the past month, ISO 8601, offsets, time zones, all that stuff.  super dry but for some reason i am getting into it, please tell no one, as this is surely a sign of mental illness.

so, a single UTC offset can correspond to multiple time zones. that's the biggie.  for example, -05:00 could represent Eastern Standard Time in the US during standard time or Central Daylight Time during DST in the US, and also other time zones in different countries. bada boom.

and speaking of DST, when a region observes daylight savings it changes their offset for part of the year. the current offset doesn't tell you whether it observes DST or if the offset is due to standard time or daylight saving.

also, rules and offsets can change over time due to political stuff, too. an offset might give you a correct time zone for the current date but could be wrong for historical or future dates.

[blue-j]

so, basically, it's a one-way function.  you can get offset from time zone, but not time zone from offset.  for example, check Google's time zone API:

https://developers.google.com/maps/documentation/timezone/requests-timezone

it *requires* not only a location but a timestamp precisely because you can't know whether DST is in play.

[Phil Harvey]

I completely understand what you are saying, but we already have a number of "TimeZone" tags which just give the offset.  I admit to being lazy and not calling these TimeZoneOffset.

- Phil

[blue-j]

No complaints from me.  I am so grateful for ExifTool!  : )

[blue-j]

Phil, Monsieur StarGeek, did either of you have joy extracting the previews from EXRs?  Maybe the issue here is the .raw -> pixels step, not in ExifTool's export...?  - J

Thanks, Phil!  I did test with test image Spirals.exr and didn't what I expected, but this format is utterly batshit flexible.  It is breaking my mind.

I have labeled the binary as .raw, and assigned dimensions of 100x (default X for EXR previews) and it does not result in clear output, more like a misshapen beastie against transparency.  have you tested with a few other samples?  which one did it work on for you?