imread/imwrite and other issues

[Thomas L. Scofield]

I was making some positive strides on imwrite.m before John Eaton's changeset on Monday, but had not figured out how to take an image passed as a parameter to a dynamically linked function like __magick_write__ and cast it to an Image type.  I will study what you've written to gain more insight.  However, I wonder if there is a body of documentation out there that would make understanding Octave's API to C++ more easily learned.  I am not a C++ programmer.  I once knew the basics, but have to re-learn them all, practically speaking.  When it comes to the Magick++ API to C++, I recently (Monday) discovered websites like

  http://www.simplesystems.org/Magick++/Image.html

(perhaps the GraphicsMagick site provides sites such as these containing such detail, but I haven't happened upon them there, but rather from the website of the author of Magick++) which not only give basic examples of code, but also provide a table of the attributes and methods (parameters, brief explanations of what they do).  Such sites provide limited information, but help streamline the process of getting to the place where I can do at least basic image operations.

All that leads to the question as to whether there is similar documentation explaining the Octave API that I have overlooked.  Without it, I have been resorting to grep-ping header files to find where various methods are declared, and then trying to infer from the header what the methods actually do (and grep-ping again to find out more about the arguments to these methods).  It's all pretty inefficient, and thus far I cannot say I've learned very much that I can use.

Next, I finally was able to compile the latest repository on my mac about a week and a half ago for the first time.  It is on that machine I would like to carry out continued development.  The crucial step was the following arguments to configure (which, I have no doubts, are not optimized):

./configure CPPFLAGS="-I/sw/include -I/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/include" LDFLAGS="-L/sw/lib/ -L/usr/lib -L/Developer/SDKs/MacOSX10.4u.sdk/usr/X11R6/lib" --prefix=/sw

This command worked insofar as the only complaint about libraries I received at the end was that "FLTK backend libs" were not found, nor were the ones "necessary to compile native graphics."  I think that this was during the time between John Eaton's changeset to imread.m and __magick_read__.cc (July 16, changesets 8123 and 8118?) and today, for I was successfully using imread.m from core Octave.  I tried the same configure command today after downloading the most recent repository, and it seemed to work even better---I still see the "didn't find the necessary libraries ..." warning, but now it is finding viable "FLTK backend libs".  Issuing "make" last week was successful, and I had a working program.  Today, make fails; here are the last few lines of output:

./DLD-FUNCTIONS/__magick_read__.cc: In function 'octave_value_list read_indexed_images(std::vector<Magick::Image, std::allocator<Magick::Image> >&, const Array<octave_idx_type>&, bool)':

./DLD-FUNCTIONS/__magick_read__.cc:143: warning: comparison between signed and unsigned integer expressions

./DLD-FUNCTIONS/__magick_read__.cc: In function 'void write_image(const std::string&, const std::string&, const octave_value&, const octave_value&)':

./DLD-FUNCTIONS/__magick_read__.cc:490: error: conversion from 'octave_int<uint8_t>' to 'MagickLib::Quantum' is ambiguous

../liboctave/oct-inttypes.h:330: note: candidates are: octave_int<T>::operator float() const [with T = uint8_t]

../liboctave/oct-inttypes.h:328: note:                 octave_int<T>::operator double() const [with T = uint8_t]

../liboctave/oct-inttypes.h:324: note:                 octave_int<T>::operator T() const [with T = uint8_t]

./DLD-FUNCTIONS/__magick_read__.cc:491: error: conversion from 'octave_int<uint8_t>' to 'MagickLib::Quantum' is ambiguous

../liboctave/oct-inttypes.h:330: note: candidates are: octave_int<T>::operator float() const [with T = uint8_t]

../liboctave/oct-inttypes.h:328: note:                 octave_int<T>::operator double() const [with T = uint8_t]

../liboctave/oct-inttypes.h:324: note:                 octave_int<T>::operator T() const [with T = uint8_t]

./DLD-FUNCTIONS/__magick_read__.cc:492: error: conversion from 'octave_int<uint8_t>' to 'MagickLib::Quantum' is ambiguous

../liboctave/oct-inttypes.h:330: note: candidates are: octave_int<T>::operator float() const [with T = uint8_t]

../liboctave/oct-inttypes.h:328: note:                 octave_int<T>::operator double() const [with T = uint8_t]

../liboctave/oct-inttypes.h:324: note:                 octave_int<T>::operator T() const [with T = uint8_t]

make[2]: *** [pic/__magick_read__.o] Error 1

make[1]: *** [src] Error 2

make: *** [all] Error 2

Can anyone tell if this is a problem on my end?

Despite not being able to use current sources, I think what I have to say about imread.m is still valid.  At least some png image files (BMP and PSD files as well, I believe) use 4 channels: red, green, blue and alpha.  For those files, imread returns an array with 4 degrees of freedom (DOFs).  (Would it do so as well for files using CMYK color space?)  As such, the matrix A in which the image is stored cannot be sent off to imshow without locking its fourth coordinate, as in imshow(A(:,:,:,1)).  The changes John Eaton made to imread.m as I submitted it were quite necessary, but in the process code I had included for locking this fourth coordinate in imread before ever returning the image was lost.  Should it be reinstated?  Or, should imshow be modified to handle the occasional image that has 4 DOFs?  I don't mind making the changes, but lean towards altering imshow instead of imread if this doesn't result in an unacceptable incompatability with Matlab.  Interestingly, when I read this same kind of png into Matlab, it returns a matrix with 2 DOFs, not 4 like in Octave and, subsequently, it displays the image as grayscale when it was really a color image (the Octave call imshow(A(:,:,:,1)) gets the color right).  (Perhaps that is remedied in Matlab with optional arguments to imread.)

Thomas L. Scofield

--------------------------------------------------------

Associate Professor

Department of Mathematics and Statistics

Calvin College

--------------------------------------------------------