Writing out to DPX produces invalid file

[magick]

We will investigate problem with DPX and get back to you. Given our current workload it may take several weeks or months before you hear from us.

[koshiji]

in coders/dpx.c
dpx.image.image_element[0].packing is always set to 0
at 10 or 12 bit depth, it shoud set to "1".

in addition, dpx.image.image_element[0].transfer and colorimetric is always 0 though default colorspace is LOG.

[magick]

Thanks for the bug report. We will get these fixes into the next point release of ImageMagick in a week or so.

[koshiji]

For LOG Color Space,

It used "Printing Density" at Transfer characteristic.

Is it right ?

[olert]

The subject is old, but I'll try anyway

>in coders/dpx.c
>dpx.image.image_element[0].packing is always set to 0
>at 10 or 12 bit depth, it shoud set to "1".

For 12bit images, setting packing to 1 causes each compunent to use 16bit on file, the 4 LSB set to 0. This is refered to as 'Method A filling' in the DPX standard (SMPTE 268M).
Using 'Method A filling' gives quite some overhead in the files, 12 bit per RGB pixel.

The DPX format also supports packing 0 for DPX files, resulting in smaller files. However the current dpx.c API dosen't support it.
My suggestion would be to either change to packing 0 also for 12 and 10 bit files, or somehow making it user configurable.