We have a Thompson/Grass Valley 4k (Spirit) film
scanner that can output single-channel DPX files, which
we use frequently when scanning black-and-white
material. Unfortunately, GraphicsMagick (1.2 snapshot
releases, up to and including the 20060604 snapshot)
can't open or manipulate these files. Here's the
typical error:
gm display start.dpx
gm display: Unexpected end-of-file (start.dpx).
gm display: Unexpected end-of-file (start.dpx).
FYI, ImageMagick originally worked with this type of
file (and I believe that the 1.1.7 version of Graphics
Magick may also work). ImageMagick's support broke
when a large DPX coder update was made, between version
6.2.2 and 6.2.3. I've e-mailed a developer on that
project who submitted a fix which is in the latest beta
(6.2.8-8) available from:
ftp://magick.imagemagick.org/pub/ImageMagick/beta
which fixes the problem with ImageMagick. Hopefully
looking at the changes can help point the way for a
GraphicsMagick fix as well.
I'm uploading a sample file. It's a 4K single-channel
image of an upside-down "START" frame as seen at the
beginning of motion picture reels.
I can upload a sample file if necessary.
Logged In: YES
user_id=128624
There are two known issues with GM and grayscale files
output from Spirit:
1) Thompson uses a wrong DPX header. The header indicates
different sample packing than is actually used. Thompson
indicates that there is not much they can/will do about this
now.
2) GraphicsMagick is currently not handling 10-bit packed
samples correctly when there are not three samples per
pixel. The problem is how to deal with samples at the end
of rows since one 32-bit word may support three pixels. The
problem is evident when the image width is not evenly
divisible by three. A fix for this is planned.
Bob
Hello Bob,
I believe I experience the same bug. I try to read 10 bit RGB files with an alpha. GraphicsMagick happily reads a 2280 pixels wide file but not a 2048. The same files at 16 bit read fine. Is this the same problem? Any ETA for a fix?
Best regards.
On Mon, 18 Jul 2016, koala wrote:
I have an idea for a way to allow this problem to be easily solved,
but the problem has been known since the DPX support was written and
the idea has not been implemented yet.
The difficulty of implementation stems from 10-bit DPX storing 3
samples per 32-bit storage value. With something other than 3 samples
per pixel, it is necessary to keep track of unused samples and save
them for the next row. This whole issue stems from GraphicsMagick
accessing pixels in rows.
DPX itself is not row-based and the samples problem is easily solved
by consuming the correct number of samples at a time.
I can not say that there is an ETA for the fix.
Bob
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/