octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel

[cwr@…]

Is this a problem with Octave or GraphicsMagick? I need to read full color (24 bit per pixel) JPEG image files into Octave. When I try I get:

octave:3> TestImage = imread('test_image.jpg', 'JPEG');
warning: your version of GraphicsMagick limits images to 8 bits per pixel
error: imread: invalid image file: invalid conversion from string to real N-d array
error: called from:
error:   /opt/local/share/octave/3.6.3/m/image/imread.m at line 74, column 7

I don't know enough about MacPorts etc., to know if the fix for this would be ("globally") in the port of GraphicsMagick, or ("locally") in Octave's dependency on GraphicsMagick. (In fact I don't understand why anyone would ever want to limit image files to 8 bit, but I guess that is off topic.)

There is a note about this issue here: ​http://wiki.octave.org/GraphicsMagick

I am running Mountain Lion (10.8.3) and Xcode 4.6.1.

Please let me know of any suggestions for a work-around in the meantime.

[michaelld (Michael Dickens)]

Sorry I didn't get back to your email query; I've been swamped with other work. I'm now in the process of upgrading octave-devel to 3.6.4 -- which probably won't fix this issue but you never know. I hope to get the upgrade in place in the next couple of days and can then work on this ticket. I know of no work-arounds at this time.

[cwr@…]

Thanks for your response. I am well acquainted with "swamped". I just decided that this was a better place for the report than in random email. From that page I cite above, it seems like a quick configuration fix, but I'm not in a position to know. Again, thanks for your work supporting the Octave port.

[ryandesign (Ryan Carsten Schmidt)]

Replying to cwr@…:

warning: your version of GraphicsMagick limits images to 8 bits per pixel

The error message is not correct. GraphicsMagick is not limited to 8 bits per pixel; it is (in its default configuration) limited to 8 bits per pixel quantum. A pixel is made up of four pixel quantums: red, green, blue, and alpha. So the default setting of 8 is 24 bits of color information and 8 bits of alpha. GraphicsMagick also supports pixel quantums of 16 bits (48 bits of color and 16 bits of alpha per pixel) and 32 bits (96 bits of color and 32 bits of alpha per pixel); you can select which one you want by using the appropriate variant when you install the port:

$ port variants GraphicsMagick
GraphicsMagick has the variants:
   q16: Use 16 bits per pixel quantum
     * conflicts with q32 q8
   q32: Use 32 bits per pixel quantum
     * conflicts with q16 q8
[+]q8: Use 8 bits per pixel quantum
     * conflicts with q16 q32
   universal: Build for multiple architectures

[ryandesign (Ryan Carsten Schmidt)]

ImageMagick, from which GraphicsMagick was forked some years ago, also supports these pixel quantum sizes, but its default is 16 bits.

The ImageMagick libraries build differently depending on the pixel quantum depth, and therefore so do any programs that link against those libraries. This causes problems, as I discussed with the ImageMagick developers ​here. Consider that our buildbot builds ports with the default variants, so ImageMagick on the buildbot was built with q16. And therefore any other ports that link with ImageMagick libraries were built on the buildbot linked with q16 ImageMagick libraries. Now imagine a user installs ImageMagick q8. Since that's not the default variant, there's no binary for it on our server, so it builds from source on the user's system. Next, the user installs some program X that uses ImageMagick libraries. Ports that use ImageMagick don't have q8, q16 and q32 variants; they just assume ImageMagick is ImageMagick. So the user could receive a binary of X that was built on the buildbot using q16, and that program will now behave incorrectly because it was built for q16 libraries but is now running with q8 libraries. Therefore, in the next ImageMagick port update, I will remove the possibility to select the pixel quantum depth and always use the default of 16. The alternative is to completely redesign the ImageMagick port, including splitting it into subports for each pixel quantum depth and revising the dependencies of every port using ImageMagick. I thought about doing this, but it's so much work. Another possible solution is to add q8, q16 and q32 variants to every port that uses ImageMagick libraries, but that's a mess too.

I do not yet know if the GraphicsMagick libraries also vary depending on pixel quantum depth but I assume they do. If they do, they're affected by the same problem, so I should remove the possibility to change the pixel quantum size from the GraphicsMagick port as well.

[cwr@…]

Replying to ryandesign@…:

Replying to cwr@…:

warning: your version of GraphicsMagick limits images to 8 bits per pixel

The error message is not correct. GraphicsMagick is not limited to 8 bits per pixel; it is (in its default configuration) limited to 8 bits per pixel quantum. A pixel is made up of four pixel quantums: red, green, blue, and alpha. So the default setting of 8 is 24 bits of color information and 8 bits of alpha. GraphicsMagick also supports pixel quantums of 16 bits (48 bits of color and 16 bits of alpha per pixel) and 32 bits (96 bits of color and 32 bits of alpha per pixel); you can select which one you want by using the appropriate variant when you install the port...

OK, so since I do only want 24 bits of RGB what is causing this error? I do not need high precision color data, in fact these are screen grabs. Does the error imply the JPEG file has more than 8 bits (per channel/primary/quanta) and it can't handle that? Nothing in the call I made insisted on 8-bit-ness. I am unclear on who is complaining about what.

[michaelld (Michael Dickens)]

Looking through ​Octave bug tracker results for imread, and in particular ​bug #35054, I think the issue is that the syntax for "imread" was changed between Octave 3.2 and 3.4. It used to be "imread(file, ext, options)" but was changed to just "imread(file, options)" -- the "ext" is no longer used. The "usage" page for "__magick_read__" reports back that the API should be "(FNAME, INDEX)" (which is not quite correct according to the Octave C++ source for this function, but that's beyond the point of this ticket, really). So, I -think- the issue with respect to this ticket is the use of the "ext" as a string, which should instead be an index value (or, not used at all).

That said, when I remove the "ext" (e.g., "a = imread('~/Desktop/b1.gif');"), it still does not work for me:

error: imread: invalid image file: Magick++ exception: Magick: No decode delegate for this image format () reported by magick/constitute.c:1522 (ReadImage)

but, at least this error is being generated withing Octave's source code for __magick_read__, which could possibly be debugged.

Here's something else fun you can try:

% MAGICK_DEBUG="Exception" octave
octave> a = imread('~/Desktop/foo.pdf')
23:24:57 0:01 0.000u 27198 blob.c/OpenBlob/2777/FileOpen:
  Unable to open file ()
23:24:57 0:01 0.000u 27198 constitute.c/ReadImage/1522/MissingDelegate:
  No decode delegate for this image format ()
error: imread: invalid image file: Magick++ exception: Magick: No decode delegate for this image format () reported by magick/constitute.c:1522 (ReadImage)

which says to me that the way GraphicsMagick is being used by Octave is not working, at least for me. I'm wondering if others can try reading various image types without the "ext" and see if it works for you? It does not for me, for any image type.

[cwr@…]

OMG. It never occurred to me to leave off imread's "optional" second argument, let alone that the calling sequence might have been changed in a non-backward-compatible way (and that I was using obsolete doc). However after michaelld's message I tried it:

TestImage = imread('test_image.jpg');

and it appears to have worked. (I put that tiny test image here: ​http://www.red3d.com/cwr/temp/test_image.jpg in case anyone wants to try.) The matrix returned from imread has dimensions 25,25,3 as expected (the image is 25x25 pixels and the third dimension is the number of channels/quanta for this RGB image). The values in the matrix are between 0 and 255, as one would expect.

I'm not sure if I'm more relieved that I can now read my data or annoyed that I had been shooting myself in the foot. In any case, thanks a million for looking at this.

[michaelld (Michael Dickens)]

You're welcome; I learned quite a bit along the way, so win-win? Anyway, I'm glad you can read images now. If you don't mind me asking, what does "port installed" return for you? I'm trying to track down why my octave-devel install isn't working.

I'm closing this ticket; I would say "works for me" but it doesn't :)

[cwr@…]

[cwr-laptop:~] cwr% port installed
The following ports are currently installed:
  aquaterm @1.1.1_0 (active)
  arpack @3.1.2_1+accelerate+gcc47+openmpi (active)
  atlas @3.10.1_3+gcc47 (active)
  autoconf @2.69_0 (active)
  automake @1.13.1_0 (active)
  bison @2.7_0 (active)
  bzip2 @1.0.6_0 (active)
  cairo @1.12.14_0+x11 (active)
  cctools @836_0+llvm32 (active)
  cctools-headers @836_1 (active)
  cloog @0.17.0_1 (active)
  cmake @2.8.10_1 (active)
  curl @7.29.0_1+ssl (active)
  curl-ca-bundle @7.29.0_0 (active)
  db46 @4.6.21_7 (active)
  expat @2.1.0_0 (active)
  fftw-3 @3.3.3_1 (active)
  fftw-3-single @3.3.3_1 (active)
  flex @2.5.37_1 (active)
  fontconfig @2.10.2_0 (active)
  freetype @2.4.10_0 (active)
  ftgl @2.1.3-rc5_0 (active)
  gawk @4.0.2_0 (active)
  gcc47 @4.7.2_2 (active)
  gcc_select @0.1_8 (active)
  gd2 @2.0.35_14 (active)
  gdbm @1.10_2 (active)
  gettext @0.18.2.1_0 (active)
  ghostscript @9.06_3 (active)
  glib2 @2.36.0_0 (active)
  glpk @4.47_0 (active)
  gmp @5.0.5_0 (active)
  gnuplot @4.6.2_0+aquaterm+luaterm+pangocairo+x11 (active)
  gobject-introspection @1.36.0_0 (active)
  gperf @3.0.4_2 (active)
  GraphicsMagick @1.3.18_0+q8 (active)
  graphite2 @1.2.1_0 (active)
  grep @2.14_0 (active)
  gsed @4.2.2_0 (active)
  harfbuzz @0.9.14_0 (active)
  hdf5-18 @1.8.10_1+cxx (active)
  help2man @1.41.1_0 (active)
  icu @49.1.2_1 (active)
  isl @0.10_1 (active)
  jasper @1.900.1_10 (active)
  jbig2dec @0.11_1 (active)
  jpeg @9_1 (active)
  lcms2 @2.4_2 (active)
  ld64 @134.9_1+llvm32 (active)
  less @451_0 (active)
  libedit @20121213-3.0_0 (active)
  libffi @3.0.13_0 (active)
  libiconv @1.14_0 (active)
  libidn @1.26_0 (active)
  libmpc @1.0.1_0 (active)
  libpaper @1.1.24_0 (active)
  libpixman @0.28.2_0 (active)
  libpng @1.5.15_0 (active)
  libstdcxx @4.7.2_2 (active)
  libtool @2.4.2_3 (active)
  libxml2 @2.9.0_0 (active)
  llvm-3.2 @3.2_1 (active)
  llvm_select @0.2_0 (active)
  lua @5.1.4_4 (active)
  lzo2 @2.06_0 (active)
  m4 @1.4.16_0 (active)
  metis @5.0.2_1 (active)
  mpfr @3.1.1-p2_0 (active)
  ncurses @5.9_2 (active)
  octave-devel @3.6.3_1+atlas+gcc47 (active)
  openmpi @1.6.4_0+gcc47 (active)
  openssl @1.0.1e_1 (active)
  p5.12-locale-gettext @1.50.0_7 (active)
  pango @1.32.5_0+x11 (active)
  pcre @8.32_1 (active)
  pdflib @7.0.5_1 (active)
  perl5 @5.12.4_0+perl5_12 (active)
  perl5.12 @5.12.4_1 (active)
  pkgconfig @0.27.1_2 (active)
  ppl @1.0_0 (active)
  python27 @2.7.3_1 (active)
  python_select @0.3_2 (active)
  qhull @2012.1_2 (active)
  qrupdate @1.1.2_2+atlas+gcc47 (active)
  readline @6.2.000_0 (active)
  sqlite3 @3.7.16_0 (active)
  SuiteSparse @4.0.0_0 (active)
  texinfo @4.13_2 (active)
  tiff @4.0.3_1 (active)
  Xft2 @2.3.1_0 (active)
  xorg-kbproto @1.0.6_0 (active)
  xorg-libice @1.0.8_0 (active)
  xorg-libpthread-stubs @0.3_0 (active)
  xorg-libsm @1.2.1_0 (active)
  xorg-libX11 @1.5.0_0 (active)
  xorg-libXau @1.0.7_0 (active)
  xorg-libxcb @1.9_0+python27 (active)
  xorg-libXdmcp @1.1.1_0 (active)
  xorg-libXext @1.3.1_0 (active)
  xorg-libXt @1.1.3_0 (active)
  xorg-renderproto @0.11.1_0 (active)
  xorg-xcb-proto @1.8_0+python27 (active)
  xorg-xcb-util @0.3.9_0 (active)
  xorg-xextproto @7.2.1_0 (active)
  xorg-xproto @7.0.23_0 (active)
  xpm @3.5.10_0 (active)
  xrender @0.9.7_0 (active)
  xz @5.0.4_0 (active)
  zlib @1.2.7_0 (active)