Re: imread.m

[Daniel J Sebald]

Daniel J Sebald wrote:

> On 15-Jul-2008, Thomas L. Scofield wrote:
>
> | Just got your message about it being imshow.  Can it be the source of  
> | the problem I describe here, too?
>
> Yes, I think the problem is that uint8 images of size MxNx3 are not
> displayed properly by imshow.  For example, try this:
>
>  imshow (uint8 (repmat (kron ((0:255)', ones (1, 200)), [1, 1, 3])))
>
> It should show a smooth black to white gradient from top to bottom,
> but I see the attached image instead.

I haven't updated to Mercurial and the latest code yet so can't put together a patch.  But I think I see what the problem is.  Perhaps a lower level routine no longer automatically ranges the data.  This test in imshow.m is true for your example:

  elseif (size (im, 3) == 3)
    if (ismember (class (im), {"uint8", "uint16", "double", "single"}))
      true_color = true;

This means it is to be an rgb image in "truecolor".  In that case, scaling of data is NOT done:

  ## Scale the image to the interval [0, 1] according to display_range.
  if (! (true_color || indexed || islogical (im)))

So, the questions are.  What does "truecolor" mean here?  Does it simply mean RGB?  Or does it mean RGB and no data scaling?  The help for imshow simply says that RGB.  If the data came from a file, I could see that no scaling should be applied.  (But that is already present as "indexed".)  But if the data comes from the command line, like John's example, I'd say no.

My thinking is that "true_color" should be removed from the scaling test above.  I don't think TrueColor images have any implicit scaling properties, just that a colormap is not used.

Dan

[John W. Eaton]

On 15-Jul-2008, Daniel J Sebald wrote:

| Daniel J Sebald wrote:
| > On 15-Jul-2008, Thomas L. Scofield wrote:
| >
| > | Just got your message about it being imshow.  Can it be the source of  
| > | the problem I describe here, too?
| >
| > Yes, I think the problem is that uint8 images of size MxNx3 are not
| > displayed properly by imshow.  For example, try this:
| >
| >  imshow (uint8 (repmat (kron ((0:255)', ones (1, 200)), [1, 1, 3])))
| >
| > It should show a smooth black to white gradient from top to bottom,
| > but I see the attached image instead.
|
| I haven't updated to Mercurial and the latest code yet so can't put together a patch.  But I think I see what the problem is.  Perhaps a lower level routine no longer automatically ranges the data.  This test in imshow.m is true for your example:
|
|   elseif (size (im, 3) == 3)
|     if (ismember (class (im), {"uint8", "uint16", "double", "single"}))
|       true_color = true;
|
| This means it is to be an rgb image in "truecolor".  In that case, scaling of data is NOT done:
|
|   ## Scale the image to the interval [0, 1] according to display_range.
|   if (! (true_color || indexed || islogical (im)))
|
| So, the questions are.  What does "truecolor" mean here?  Does it simply mean RGB?  Or does it mean RGB and no data scaling?  The help for imshow simply says that RGB.  If the data came from a file, I could see that no scaling should be applied.  (But that is already present as "indexed".)  But if the data comes from the command line, like John's example, I'd say no.
|
| My thinking is that "true_color" should be removed from the scaling test above.  I don't think TrueColor images have any implicit scaling properties, just that a colormap is not used.

The following patch seems to fix the problem for me, and also improves
compatibility with regard to the way cdata is stored and clim is
computed.  But maybe I messed up something else with this change, so
it would help if people who work with images could do some testing.

Thanks,

jwe


# HG changeset patch
# User John W. Eaton <jwe@...>
# Date 1216221888 14400
# Node ID 1f6eb3de1c4ef4726e14cb4a7f945f059b5fd087
# Parent  30b952e90c294c6601e8f812e8a746024f91fd5a
__img__.m, imshow.m, __go_draw_axes__.m: improve handling of truecolor images

diff --git a/scripts/ChangeLog b/scripts/ChangeLog
--- a/scripts/ChangeLog
+++ b/scripts/ChangeLog
@@ -1,3 +1,11 @@
[phone]  John W. Eaton  <jwe@...>
+
+ * image/__img__.m: Set clim for true-color integer data.
+
+ * image/imshow.m: Don't convert integer true-color data to double.
+
+ * plot/__go_draw_axes__.m: Recognize 3-d cdata as a true-color image.
+
 2008-07-14  John W. Eaton  <jwe@...>
 
  * image/Makefile.in (SOURCES): Add imread.m to the list.
diff --git a/scripts/image/__img__.m b/scripts/image/__img__.m
--- a/scripts/image/__img__.m
+++ b/scripts/image/__img__.m
@@ -56,6 +56,15 @@
   tmp = __go_image__ (ca, "cdata", img, "xdata", xlim, "ydata", ylim,
       "cdatamapping", "direct", varargin {:});
 
+  if (ndims (img) == 3)
+    if (isinteger (img))
+      c = class (img);
+      mn = intmin (c);
+      mx = intmax (c);
+      set (ca, "clim", double ([mn, mx]));
+    endif
+  endif
+
   set (ca, "view", [0, 90]);
 
   if (strcmp (get (ca, "nextplot"), "replace"))
diff --git a/scripts/image/imshow.m b/scripts/image/imshow.m
--- a/scripts/image/imshow.m
+++ b/scripts/image/imshow.m
@@ -147,7 +147,7 @@
   endif
 
   ## This is for compatibility.
-  if (! indexed || islogical (im))
+  if (! (indexed || (true_color && isinteger (im))) || islogical (im))
     im = double (im);
   endif
 
diff --git a/scripts/plot/__go_draw_axes__.m b/scripts/plot/__go_draw_axes__.m
--- a/scripts/plot/__go_draw_axes__.m
+++ b/scripts/plot/__go_draw_axes__.m
@@ -291,6 +291,7 @@
     zautoscale = strcmpi (axis_obj.zlimmode, "auto");
     cautoscale = strcmpi (axis_obj.climmode, "auto");
     cdatadirect = false;
+    truecolor = false;
 
     kids = axis_obj.children;
 
@@ -338,7 +339,9 @@
 
   if (use_gnuplot_for_images)
 
-    if (strcmpi (obj.cdatamapping, "direct"))
+    if (ndims (img_data) == 3)
+      truecolor = true;
+    elseif (strcmpi (obj.cdatamapping, "direct"))
       cdatadirect = true;
     endif
     fputs (plot_stream, "set border front;\n");
@@ -1056,11 +1059,12 @@
 
     cmap = parent_figure_obj.colormap;    
     cmap_sz = rows(cmap);
+
     if (! any (isinf (clim)))
-      if (cdatadirect)
+      if (truecolor || ! cdatadirect)
+ fprintf (plot_stream, "set cbrange [%g:%g];\n", clim);
+      else
  fprintf (plot_stream, "set cbrange [1:%d];\n", cmap_sz);
-      else
- fprintf (plot_stream, "set cbrange [%g:%g];\n", clim);
       endif
     endif
 

[John W. Eaton]

On 16-Jul-2008, John W. Eaton wrote:

| The following patch seems to fix the problem for me, and also improves
| compatibility with regard to the way cdata is stored and clim is
| computed.  But maybe I messed up something else with this change, so
| it would help if people who work with images could do some testing.

I've also now checked in some changes to imread so that it will first
try __magick_read__, then attempt to read Octave's image format (the
file format that was originally handled by loadimage).  The loadimage
function is now deprecated.

These changes seem to work for me but could probably use some
additional testing.

Thanks,

jwe

[David Bateman-3]

John W. Eaton wrote:

> On 16-Jul-2008, John W. Eaton wrote:
>
> | The following patch seems to fix the problem for me, and also improves
> | compatibility with regard to the way cdata is stored and clim is
> | computed.  But maybe I messed up something else with this change, so
> | it would help if people who work with images could do some testing.
>
> I've also now checked in some changes to imread so that it will first
> try __magick_read__, then attempt to read Octave's image format (the
> file format that was originally handled by loadimage).  The loadimage
> function is now deprecated.
>
> These changes seem to work for me but could probably use some
> additional testing.
>
> Thanks,
>
> jwe
>

Could the attached changeset also be committed as currently Octaev can't
be built if GraphicsMagick is not installed.

D.


# HG changeset patch
# User David Bateman <dbateman@...>
# Date 1216287806 -7200
# Node ID c3608df3b40cc1e218daccf9057d743cc0144ae2
# Parent  1eedd77a192ee39d5b1813e589efeb521df852d0
Allow build without GraphicsMagick installed

diff --git a/ChangeLog b/ChangeLog
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@ 2008-07-16  Michael Goffioul  <michael.g
[phone]  David Bateman  <dbateman@...>
+
+ * configure.in (HAVE_MAGICK): New define for presence of
+ GraphicsMagick.
+
 2008-07-16  Michael Goffioul  <michael.goffioul@...>
 
  * configure.in: Add check for pthread.h.
diff --git a/configure.in b/configure.in
--- a/configure.in
+++ b/configure.in
@@ -641,6 +641,8 @@ AC_CHECK_PROGS(MAGICK_CONFIG, [GraphicsM
 AC_CHECK_PROGS(MAGICK_CONFIG, [GraphicsMagick++-config GraphicsMagick-config])
 if test -z "$MAGICK_CONFIG"; then
   warn_magick="GraphicsMagick++ config script not found.  Assuming GraphicsMagic++ library and header files are missing, so imread will not be fully functional"
+else
+  AC_DEFINE(HAVE_MAGICK, 1, [Define if GraphicsMagick++ is available.])
 fi
 
 # ---------------------------------------------------------------------
diff --git a/src/ChangeLog b/src/ChangeLog
--- a/src/ChangeLog
+++ b/src/ChangeLog
@@ -1,3 +1,8 @@ 2008-07-15  John W. Eaton  <jwe@...
[phone]  David Bateman  <dbateman@...>
+
+ * DLD-FUNCTION/__magick_read__.cc (F__magick_read__): Allow build
+ without GraphicsMagick++ installed.
+
 2008-07-15  John W. Eaton  <jwe@...>
 
  * DLD-FUNCTIONS/__convn__.cc (convn): Cast second arg to
diff --git a/src/DLD-FUNCTIONS/__magick_read__.cc b/src/DLD-FUNCTIONS/__magick_read__.cc
--- a/src/DLD-FUNCTIONS/__magick_read__.cc
+++ b/src/DLD-FUNCTIONS/__magick_read__.cc
@@ -27,6 +27,8 @@ along with Octave; see the file COPYING.
 
 #include "defun-dld.h"
 #include "error.h"
+
+#ifdef HAVE_MAGICK
 
 #include <GraphicsMagick/Magick++.h>
 
@@ -303,6 +305,7 @@ read_images (const std::vector<Magick::I
 
   return retval;
 }
+#endif // HAVE_MAGICK
 
 DEFUN_DLD (__magick_read__, args, nargout,
   "-*- texinfo -*-\n\
@@ -316,6 +319,7 @@ Instead you should use @code{imread}.\n\
 {
   octave_value_list output;
 
+#ifdef HAVE_MAGICK
   if (args.length () > 2 || args.length () < 1 || ! args(0).is_string ()
       || nargout > 3)
     {
@@ -401,6 +405,11 @@ Instead you should use @code{imread}.\n\
   error ("__magick_read__: image depths bigger than 16-bit not supported");
  }
     }
+#else
+
+  error ("__magick_read__: not available in this version of Octave");
+
+#endif
 
   return output;
 }

[John W. Eaton]

On 17-Jul-2008, David Bateman wrote:

| Could the attached changeset also be committed as currently Octaev can't
| be built if GraphicsMagick is not installed.

I applied it.

Thanks,

jwe