Page 1 of 1
Posted: 2006-09-27T15:57:22-07:00
by 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.
Posted: 2007-01-23T04:54:28-07:00
by 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.
Posted: 2007-01-23T06:07:44-07:00
by magick
Thanks for the bug report. We will get these fixes into the next point release of ImageMagick in a week or so.
Re: Writing out to DPX produces invalid file
Posted: 2007-09-27T19:28:22-07:00
by koshiji
For LOG Color Space,
It used "Printing Density" at Transfer characteristic.
Is it right ?
Re: Writing out to DPX produces invalid file
Posted: 2012-11-09T06:19:34-07:00
by 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.