[MacPorts] #38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel --------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Keywords: | Port: octave-devel --------------------+-------------------------------- 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. -- Ticket URL: <https://trac.macports.org/ticket/38730> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by michaelld@…): 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Changes (by ryandesign@…): * cc: ryandesign@… (added) Comment: Replying to [ticket:38730 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 }}} -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by ryandesign@…): 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 [http://www.imagemagick.org/discourse- server/viewtopic.php?f=2&t=22932&p=95966 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 [ticket:38134 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by cwr@…): Replying to [comment:3 ryandesign@…]:
Replying to [ticket:38730 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by michaelld@…): Looking through [https://savannah.gnu.org/search/?words=imread&type_of_search=bugs&Search=Sea... Octave bug tracker results for imread], and in particular [https://savannah.gnu.org/bugs/?func=detailitem&item_id=35054 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by 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. -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Changes (by michaelld@…): * status: new => closed * resolution: => invalid Comment: 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 :) -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#38730: octave-devel @3.6.3 GraphicsMagick limits images to 8 bits per pixel ---------------------------+-------------------------------- Reporter: cwr@… | Owner: macports-tickets@… Type: defect | Status: closed Priority: Normal | Milestone: Component: ports | Version: 2.1.3 Resolution: invalid | Keywords: Port: octave-devel | ---------------------------+-------------------------------- Comment (by 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) }}} -- Ticket URL: <https://trac.macports.org/ticket/38730#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts