Possible EXR conversion issues on macOS

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
flip
Posts: 4
Joined: 2018-08-04T12:21:38-07:00
Authentication code: 1152

Possible EXR conversion issues on macOS

Post by flip »

Greetings-
I have a few .hdr images I need to convert into .exr. Easy peasy.

Doing manual conversion w/ Photoshop CC I get useable/openable images. These images are compressed without an alpha channel and using the standard wavelet compression for OpenEXR.

When I convert with ImageMagick 7.0.8-8 Q16 x86_64 2018-07-23 I get files that macOS 'Preview' can read/open OK, but these files can't be read by Photoshop (or several other programs I'm using).

[edit] Note that I'm trying to use the proper compression setting and alpha channel spec, but with no luck:

Code: Select all

$ convert atrium_desat.hdr -alpha off -compress Piz atrium_desatIM.exr
[additional edit] If I try to inspect the Photoshop-generated image using ImageMagick, I am greets with

Code: Select all

photon:Maps$ identify -verbose atrium_desatPS.exr
identify: no decode delegate for this image format `EXR' @ error/constitute.c/ReadImage/512.
[one more] And finally- the EXR tools don't 'recognize' the files created as EXR files, but PS does...

Code: Select all

photon:Maps$ exrinfo atrium_desatIM.exr
Cannot read image file "atrium_desatIM.exr". File is not an image file.
photon:Maps$ exrinfo atrium_desatPS.exr

atrium_desatPS.exr:

file format version: 2, flags 0x0
channels (type chlist):
    B, 16-bit floating-point, sampling 1 1
    G, 16-bit floating-point, sampling 1 1
    R, 16-bit floating-point, sampling 1 1
compression (type compression): piz
dataWindow (type box2i): (0 0) - (4095 2047)
displayWindow (type box2i): (0 0) - (4095 2047)
lineOrder (type lineOrder): increasing y
pixelAspectRatio (type float): 1
screenWindowCenter (type v2f): (0 0)
screenWindowWidth (type float): 1
type (type string): "scanlineimage"
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible EXR conversion issues on macOS

Post by fmw42 »

I am not an expert on HDR nor EXR, though I have on occasion used both on my Mac. But there is no listing for -compress Piz at https://www.imagemagick.org/script/comm ... p#compress. Nor is there a define for it at EXR on https://www.imagemagick.org/script/formats.php.

Also you need to have an HDRI compile of Imagemagick at least at Q16 do deal properly with high dynamic range images such as HDR and EXR. That should be the default for IM 7. If you use

Code: Select all

magick -version
it should say HDRI on the Features line.

You also need to have installed OpenEXR.

As far as I know, Imagemagick can only read/write 16-bit "half" EXR format, at least, the last I knew.

I think for you to get help from the IM developers, you should post a link to your HDR input image and to your IM created EXR output image. The developers will need to be able to reproduce your problem.


This works fine for me on IM 7.0.8.8 Q16 HDRI Mac OSX Sierra using the HDR image from http://www.mit.edu/~yzli/hdr_companding.htm

Code: Select all

magick doll.hdr -alpha off doll.exr
I can open it fine in my Photoshop CC 2018
flip
Posts: 4
Joined: 2018-08-04T12:21:38-07:00
Authentication code: 1152

Re: Possible EXR conversion issues on macOS

Post by flip »

The addition of piz compression is mentioned here on the forum from a long time ago viewtopic.php?t=14540

This might clear things up:

Code: Select all

photon:Desktop$ convert -list compress
B44
B44A
BZip
DXT1
DXT3
DXT5
Fax
Group4
JBIG1
JBIG2
JPEG
JPEG2000
Lossless
LosslessJPEG
LZMA
LZW
None
Piz
Pxr24
RLE
Zip
RunlengthEncoded
ZipS
YZ's page doesn't link to the HDR anymore. I'll email her/Ted and get it edit: got it - if anyone else needs it: https://flipphillips.com/drop/doll_doll.hdr.

In the mean time, if you'd like to try, here's one of the hdrs https://www.dropbox.com/s/0ss27xuwkjztc ... t.hdr?dl=0

Followup:

Code: Select all

photon:Downloads$ magick doll_doll.hdr -alpha off doll_doll.exr
results in a file that, as above, will open in Preview, but won't open in Photoshop CC 2018

Image

And, like above, exrinfo doesn't think its an image.

Code: Select all

photon:Downloads$ exrinfo doll_doll.exr
Cannot read image file "doll_doll.exr". File is not an image file.
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible EXR conversion issues on macOS

Post by fmw42 »

Thanks for the link and the check with

convert -list compress

You are correct, in that it does show there. So the old IM documentation needs updating.

The command

Code: Select all

magick doll_doll.hdr -alpha off doll_doll.exr
Works fine for me and opens in Photoshop CC 2018 fine. I am using Imagemagick 7.0.8.9 Q16 HDRI on Mac OSX Sierra with openexr 2.2.0_1

Your other image works fine for me also using:

Code: Select all

atrium_desat.hdr -alpha off -compress Piz atrium_desatIM.exr
and opens fine in Photoshop CC 2018.

I do get an OPENEXR prompt to choose Alpha Channel Data:

1) As transparency

2) As Alpha

I chose 1), but both work for me and the Channels windows in PS shows no alpha or transparency.

What version of OpenEXR are you using?
flip
Posts: 4
Joined: 2018-08-04T12:21:38-07:00
Authentication code: 1152

Re: Possible EXR conversion issues on macOS

Post by flip »

Code: Select all

photon:Downloads$ magick --version
Version: ImageMagick 7.0.8-9 Q16 x86_64 2018-08-08 https://www.imagemagick.org
Copyright: © 1999-2018 ImageMagick Studio LLC
License: https://www.imagemagick.org/script/license.php
Features: Cipher DPC HDRI Modules
Delegates (built-in): bzlib freetype jng jpeg ltdl lzma png tiff xml zlib
I'm using the Brew build- so maybe I'll just build it myself and see what's up. Lots of possible silliness possible w/ linking / etc.

Whoops- also

Code: Select all

/usr/local/Cellar/openexr/2.2.0_1
And-

Code: Select all

photon:Downloads$ otool -L `which magick`
/usr/local/bin/magick:
	/usr/local/Cellar/imagemagick/7.0.8-9/lib/libMagickCore-7.Q16HDRI.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/local/Cellar/imagemagick/7.0.8-9/lib/libMagickWand-7.Q16HDRI.6.dylib (compatibility version 7.0.0, current version 7.0.0)
	/usr/local/opt/freetype/lib/libfreetype.6.dylib (compatibility version 23.0.0, current version 23.1.0)
	/usr/lib/libxml2.2.dylib (compatibility version 10.0.0, current version 10.9.0)
	/usr/local/opt/xz/lib/liblzma.5.dylib (compatibility version 8.0.0, current version 8.4.0)
	/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version 1.0.5)
	/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
	/usr/local/opt/libtool/lib/libltdl.7.dylib (compatibility version 11.0.0, current version 11.1.0)
	/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4)

One more thing- the 'converted' files from IM think they are still Radiance/HDR files, at least magic cookie wise-the PS converted identify correctly. Hmph- I'm wondering if there is other mayhem / path / library linking things on my end, since it looks like we're running the same thing, same OpenEXR, etc.

Code: Select all

photon:Downloads$ file doll_doll*
doll_doll.hdr:   Radiance HDR image data
doll_dollIM.exr: Radiance HDR image data
doll_dollPS.exr: OpenEXR image data, version 2, storage: scanline, compression: piz, dataWindow: (0 0)-(921 900), displayWindow: (0 0)-(921 900), lineOrder: increasing y
Ewww- I think I might be on to something here-

Code: Select all

photon:bin$ which exrinfo
/Applications/Pixar/RenderManProServer-21.6/bin/exrinfo
User avatar
fmw42
Posts: 25562
Joined: 2007-07-02T17:14:51-07:00
Authentication code: 1152
Location: Sunnyvale, California, USA

Re: Possible EXR conversion issues on macOS

Post by fmw42 »

Imagemagick does not see OpenEXR as a delegate. So you may have added it, but it must be installed with Imagemagick.

Here is what I get from magick -version

Version: ImageMagick 6.9.10-9 Q16 x86_64 2018-08-06 https://www.imagemagick.org
Copyright: © 1999-2018 ImageMagick Studio LLC
License: https://www.imagemagick.org/script/license.php
Features: Cipher DPC Modules OpenMP
Delegates (built-in): bzlib cairo djvu fftw fontconfig freetype gslib gvc jbig jng jp2 jpeg lcms lqr ltdl lzma openexr png ps raw rsvg tiff webp x xml zlib

You also need ffmpeg installed for the mp4 (mpeg), though it won't show in the list of delegates, since I have it, but it does not show. Nevertheless Imagemagick needs to find it.

P.S. I install all my delegates from MacPorts, then install Imagemagick from source. See viewtopic.php?f=1&t=21502&p=88202&hilit ... rts#p88202


Also more delegates show up from

magick -list configure

in the Delegates section. Here is lists mpeg, which means that I have ffmpeg installed.


DELEGATES bzlib djvu mpeg fftw fontconfig freetype gslib jbig jng jpeg lcms lqr lzma openexr openjp2 png ps raw rsvg tiff webp x xml zlib
snibgo
Posts: 12159
Joined: 2010-01-23T23:01:33-07:00
Authentication code: 1151
Location: England, UK

Re: Possible EXR conversion issues on macOS

Post by snibgo »

flip wrote:Delegates (built-in): bzlib freetype jng jpeg ltdl lzma png tiff xml zlib
So your version of IM can't make exr-format files. It will happily make files with extension ".exr", but they won't contain exr-format data. The data format will be whatever the input was. So IM will read them (by ignoring the extension), but other software may not (because they expect the extension to say what the format is, or because they can't read the actual format).
snibgo's IM pages: im.snibgo.com
flip
Posts: 4
Joined: 2018-08-04T12:21:38-07:00
Authentication code: 1152

Re: Possible EXR conversion issues on macOS

Post by flip »

It will happily make files with extension ".exr", but they won't contain exr-format data.
Ah hah! Yes- totally explains it. I wasn't aware of this particular behavior. Thanks so much. Building a fresh version now... for some reason I naively expected it to grab the other delegates at run-time instead of at compile time (since it had the 'Built-in' qualifier on that line.
Post Reply