Menu

#48 DPX coder cannot manipulate single-channel images

v1.0_(example)
open
Algorithms (87)
5
2016-07-18
2006-08-02
Alan Hagge
No

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.

Discussion

  • Bob Friesenhahn

    Bob Friesenhahn - 2006-08-07

    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

     
  • koala

    koala - 2016-07-18

    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.

     
    • Bob Friesenhahn

      Bob Friesenhahn - 2016-07-18

      On Mon, 18 Jul 2016, koala wrote:

      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?

      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/

       

Log in to post a comment.