Re: imread image sizing

classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

JD Cole
Hi Ross,
    I've come across this before too. If you follow the trail of
functions that 'imshow' actually uses, you'd see that after it creates a
colormap and an indexed image from the r/g/b parameters, it uses the
'image' command to display them. 'image' takes  a scale parameter, but
in this case, imshow doesn't pass one, in the case of no scale
parameter, 'image' decides to make a scaled image, hence, your 320x240.
You got a couple of choices, you could create you're own version of
'imshow' and add a scale parameter, something like this

imshow (a1, a2, a3, scale)
....
....
image (a1, scale)
....
....
or at the very least

....
image (a1, 1)
....

This problem bothers me often too, but I'm not sure what the mainstream
solution would be since changing the definition for 'imshow', as
distributed with octave, would break from compatibility with other
numerical programs which shall remain un-named.

Maintainers have any thoughts?

JD
Ross Vandegrift wrote:

>Hello everyone,
>
> I'm working on an image analysis project, and am using imread to
>read in a color 640x480 JPEG file and sample some points.
>
> Oddly though, when read in and displayed, the graphic is
>displayed as 320x240.  If I manually run "display eye.jpg", the image is
>loaded as 640x480.  I've tried setting "-size 640x480" and "-sample
>640x480" in the options, neither one helps.
>
> Here's how I'm loading/displaying my image:
>
>[red, green, blue] = imread('jpg:eye.jpg', ["-size 640x480";]);
>red = red / 255;
>blue = blue / 255;
>green = green / 255;
>imshow(red, green, blue)
>
> It's not a critical problem or anything - I'm still able to work
>on the project at 320x240, but is there something I can do to get
>640x480?
>
>Thanks!
>  
>



Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Daniel Sebald
Allow me to elaborate on what JD said...   I think I see what the issue
is.  I just looked inside the "image.m" file.  There is a silly little
unsuspecting variable called "zoom".  Maybe a "help image" will describe
what that is.  Anyway, it looks like a parameter that if NOT specified
will be chosen so that it always attempts a resolution of 350 x 600, but
it uses rounding to the nearest integer.  So in your case, Ross, the
result is probably 1/2, i.e., the 320x240 you describe.

My preference would be to simply set the zoom equal to 1.0 if the
variable is not specified.  Anyway...  Since you cannot specify the zoom
parameter in imshow() and pass it to image(), which imshow() uses, I
suggest just using image() instead.  Here are the three commands that
imshow() uses if there are three arguments, i.e., R G B.

    [a1, a2] = rgb2ind (a1, a2, a3);
    colormap (a2);
  image (a1);

So do those directly and change the last command so that it reads

image([],[],a1,1);

Hopefully that will force the 'x' and 'y' to be generated by the routine
and force the resolution to stay just as it is.

I'm not sure this truely allows RGB images.  (Unless the colormap
happens to be huge.)  But, give that a try.  Glad you pointed this out,
because I too probably would have been bitten by this along the way.

Dan


JD Cole wrote:

> Hi Ross,
>    I've come across this before too. If you follow the trail of
> functions that 'imshow' actually uses, you'd see that after it creates
> a colormap and an indexed image from the r/g/b parameters, it uses the
> 'image' command to display them. 'image' takes  a scale parameter, but
> in this case, imshow doesn't pass one, in the case of no scale
> parameter, 'image' decides to make a scaled image, hence, your
> 320x240. You got a couple of choices, you could create you're own
> version of 'imshow' and add a scale parameter, something like this
>
> imshow (a1, a2, a3, scale)
> ....
> ....
> image (a1, scale)
> ....
> ....
> or at the very least
>
> ....
> image (a1, 1)
> ....
>
> This problem bothers me often too, but I'm not sure what the
> mainstream solution would be since changing the definition for
> 'imshow', as distributed with octave, would break from compatibility
> with other numerical programs which shall remain un-named.
>
> Maintainers have any thoughts?
>
> JD
> Ross Vandegrift wrote:
>
>> Hello everyone,
>>
>>     I'm working on an image analysis project, and am using imread to
>> read in a color 640x480 JPEG file and sample some points.
>>
>>     Oddly though, when read in and displayed, the graphic is
>> displayed as 320x240.  If I manually run "display eye.jpg", the image is
>> loaded as 640x480.  I've tried setting "-size 640x480" and "-sample
>> 640x480" in the options, neither one helps.
>>
>>     Here's how I'm loading/displaying my image:
>>
>> [red, green, blue] = imread('jpg:eye.jpg', ["-size 640x480";]);
>> red = red / 255;
>> blue = blue / 255;
>> green = green / 255;
>> imshow(red, green, blue)
>>
>>     It's not a critical problem or anything - I'm still able to work
>> on the project at 320x240, but is there something I can do to get
>> 640x480?
>>
>> Thanks!
>>  
>>
>
>
>
>

--

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/




Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

John W. Eaton-6
On 10-Mar-2004, Daniel J Sebald <[hidden email]> wrote:

| Allow me to elaborate on what JD said...   I think I see what the issue
| is.  I just looked inside the "image.m" file.

Most of the files in Octave's image directory are quite old.  They
were some of the first .m files contributed to Octave, back in 1994.

Way back then, playing with images was something fairly new to me, and
I didn't always have a terminal that could display images (about half
of my time working on Octave was done on a vt220-compatible terminal
that only supported Tektronix line graphics, not bitmap graphics).

Since those dark and terrible days, there have been lots of changes in
the way people work, and in what capabilities are expected for image
processing functions, but not much has changed in Octave's
scripts/image directory.  So now might be a good time for someone (but
not me -- I am busy enough with other projects) to start revising
Octave's image processing capabilities, preferably in a way that is
compatible with the other leading brand.  I have not looked to see
what is available in octave-forge, but that would be a good place to
start.

Finally, if you would like to have the functions you write become a
part of Octave, then please follow Octave's coding conventions, use
Texinfo markup for the doc strings, etc.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Daniel Sebald
OK.  I could possibly do that, but it would be post 4.0 of gnuplot.

Dan


John W. Eaton wrote:

>On 10-Mar-2004, Daniel J Sebald <[hidden email]> wrote:
>
>| Allow me to elaborate on what JD said...   I think I see what the issue
>| is.  I just looked inside the "image.m" file.
>
>Most of the files in Octave's image directory are quite old.  They
>were some of the first .m files contributed to Octave, back in 1994.
>
>Way back then, playing with images was something fairly new to me, and
>I didn't always have a terminal that could display images (about half
>of my time working on Octave was done on a vt220-compatible terminal
>that only supported Tektronix line graphics, not bitmap graphics).
>
>Since those dark and terrible days, there have been lots of changes in
>the way people work, and in what capabilities are expected for image
>processing functions, but not much has changed in Octave's
>scripts/image directory.  So now might be a good time for someone (but
>not me -- I am busy enough with other projects) to start revising
>Octave's image processing capabilities, preferably in a way that is
>compatible with the other leading brand.  I have not looked to see
>what is available in octave-forge, but that would be a good place to
>start.
>
>Finally, if you would like to have the functions you write become a
>part of Octave, then please follow Octave's coding conventions, use
>Texinfo markup for the doc strings, etc.
>
>Thanks,
>
>jwe
>
>
>
>  
>

--

Dan Sebald
email: daniel DOT sebald AT ieee DOT org
URL: http://acer-access DOT com/~dsebald AT acer-access DOT com/




Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

John W. Eaton-6
On 10-Mar-2004, Daniel J Sebald <[hidden email]> wrote:

| OK.  I could possibly do that, but it would be post 4.0 of gnuplot.

Why would it require gnuplot 4.0?

It seems to me that most image processing functions are not about
display, and for display, we should choose the display method rather
than forcing gnuplot to be the only method.

jwe


Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Daniel Sebald


John W. Eaton wrote:

>On 10-Mar-2004, Daniel J Sebald <[hidden email]> wrote:
>
>| OK.  I could possibly do that, but it would be post 4.0 of gnuplot.
>
>Why would it require gnuplot 4.0?
>
>It seems to me that most image processing functions are not about
>display, and for display, we should choose the display method rather
>than forcing gnuplot to be the only method.
>

Well, it sounds to me like the discussion list had some agreement that
Octave should be built to have alternative and selectable (whether it be
at compile time or whatever) display methods.  That's fine.  That should
be incorporated.  That actually may be something bigger than just the
image routines.  But of course I would take that into consideration.

 From my perspective, I'm interested in Gnuplot images, for the simple
fact that it can generate x11, PostScript, EPS, combination
PostScript/LaTeX.  There is a good chance post-4.0 Gnuplot will have
image support early on.  That would be my starting point for organizing
the image.m file.  In fact, I've written my own version of image.m that
will check the current version of Gnuplot and if the version is less
than a certain number, Octave will default to its current image viewer.

So, my initial motivation would be a nice complete display environment
based upon Gnuplot, and then later other graphics packages could be
swapped in.  That probably means that there needs to be an Octave
graphics variable set at compile time so that image.m can know what
graphics system it is supposed to use.  Otherwise, image.m would need to
be turned into an internal routine.

Dan





Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Paul Kienzle

On Mar 10, 2004, at 5:56 PM, Daniel J Sebald wrote:
>
> So, my initial motivation would be a nice complete display environment
> based upon Gnuplot, and then later other graphics packages could be
> swapped in.  That probably means that there needs to be an Octave
> graphics variable set at compile time so that image.m can know what
> graphics system it is supposed to use.  Otherwise, image.m would need
> to be turned into an internal routine.

Or you could use the graceplot (and plplot?) approach of having
different plotting libraries in different directories, and let the
LOADPATH variable do the work.

Paul Kienzle
[hidden email]


Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Daniel Sebald


Paul Kienzle wrote:

>
> On Mar 10, 2004, at 5:56 PM, Daniel J Sebald wrote:
>
>>
>> So, my initial motivation would be a nice complete display
>> environment based upon Gnuplot, and then later other graphics
>> packages could be swapped in.  That probably means that there needs
>> to be an Octave graphics variable set at compile time so that image.m
>> can know what graphics system it is supposed to use.  Otherwise,
>> image.m would need to be turned into an internal routine.
>
>
> Or you could use the graceplot (and plplot?) approach of having
> different plotting libraries in different directories, and let the
> LOADPATH variable do the work.


Do you mean the way graceplot (plplot) is organized?  Or the way that
Octave uses graceplot (plplot)?

So in that approach there might be subfunctions such as __image__.m in
different directories, e.g.,

/m/plot/xv
/m/plot/imagemagick
/m/plot/gnuplot
/m/plot/graceplot
/m/plot/plplot

?

Should work.  I will think that over.

Dan



Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

Stéfan van der Walt
In reply to this post by John W. Eaton-6
I wrote a patch to fix the zooming a while ago.  Maybe you'd find it useful:

http://www.octave.org/mailing-lists/bug-octave/2004/132

The encoding on that e-mail went horribly wrong, so I attach a version
here as well.

Regards
Stéfan

Ross Vandegrift wrote:

> On Wed, Mar 10, 2004 at 01:18:12PM -0600, John W. Eaton wrote:
>
>>scripts/image directory.  So now might be a good time for someone (but
>>not me -- I am busy enough with other projects) to start revising
>>Octave's image processing capabilities, preferably in a way that is
>>compatible with the other leading brand.  I have not looked to see
>>what is available in octave-forge, but that would be a good place to
>>start.
>
>
> I was actually under the impression that all of Octave's image
> processing came from octave-forge.  Shows what I know! ::-)
>
> Depending on how much use it gets, I may fix the scaling problem I ran
> into or clean up some of the octave-force stuff for inclusion.  Depends
> on how much image processing is a part of this semester's numerics
> class.
>

*** /tmp/imshow.m 2004-02-14 11:06:00.000000000 +0200
--- imshow.m 2004-02-24 00:25:24.000000000 +0200
***************
*** 18,59 ****
  ## 02111-1307, USA.
 
  ## -*- texinfo -*-
! ## @deftypefn {Function File} {} imshow (@var{x}, @var{map})
  ## @deftypefnx {Function File} {} imshow (@var{x}, @var{n})
  ## @deftypefnx {Function File} {} imshow (@var{i}, @var{n})
  ## @deftypefnx {Function File} {} imshow (@var{r}, @var{g}, @var{b})
! ## Display images.
  ##
! ## @code{imshow (@var{x})} displays an indexed image using the current
! ## colormap.
  ##
  ## @code{imshow (@var{x}, @var{map})} displays an indexed image using the
  ## specified colormap.
  ##
! ## @code{imshow (@var{i}, @var{n})} displays a gray scale intensity image.
  ##
  ## @code{imshow (@var{r}, @var{g}, @var{b})} displays an RGB image.
  ## @end deftypefn
  ## @seealso{image, imagesc, colormap, gray2ind, and rgb2ind}
 
  ## Author: Tony Richardson <[hidden email]>
  ## Created: July 1994
  ## Adapted-By: jwe
 
! function imshow (a1, a2, a3)
 
!   if (nargin < 0 || nargin > 3)
!     usage ("imshow (args)");
!   elseif (nargin == 2)
!     if (length (a2) == 1)
!       [a1, a2] = gray2ind (a1, a2);
      endif
-     colormap (a2);
-   elseif (nargin == 3)
-     [a1, a2] = rgb2ind (a1, a2, a3);
-     colormap (a2);
    endif
 
!   image (a1);
 
  endfunction
--- 18,134 ----
  ## 02111-1307, USA.
 
  ## -*- texinfo -*-
! ## @deftypefn {Function File} {} imshow (@var{i})
! ## @deftypefnx {Function File} {} imshow (@var{x}, @var{map})
  ## @deftypefnx {Function File} {} imshow (@var{x}, @var{n})
  ## @deftypefnx {Function File} {} imshow (@var{i}, @var{n})
  ## @deftypefnx {Function File} {} imshow (@var{r}, @var{g}, @var{b})
! ## Display an image.
  ##
! ## @code{imshow (@var{x})} displays an intensity image, estimating the
! ## number of gray levels.
  ##
  ## @code{imshow (@var{x}, @var{map})} displays an indexed image using the
  ## specified colormap.
  ##
! ## @code{imshow (@var{i}, @var{N})} displays a gray scale intensity image of
! ## N levels.
  ##
  ## @code{imshow (@var{r}, @var{g}, @var{b})} displays an RGB image.
+ ##
+ ## The string @code{truesize} can always be used as an optional
+ ## final argument to prevent automatic zooming of the image.
  ## @end deftypefn
+ ##
  ## @seealso{image, imagesc, colormap, gray2ind, and rgb2ind}
 
  ## Author: Tony Richardson <[hidden email]>
  ## Created: July 1994
  ## Adapted-By: jwe
+ ## Modified: Stefan van der Walt <[hidden email]>, 23/02/2004
+ ##           Added 'truesize' functionality.  Made function more          
+ ##           robust against different image scalings.  imshow(x)
+ ##           now ignores the current colormap.  Added unit tests
+ ##           and demos.
+
+ function imshow (varargin)
 
!   usage_str = "imshow (x) || imshow(x, map) || imshow(i, N) || imshow(r,g,b)";
 
!   if (nargin == 0 || nargin > 4)
!     usage (usage_str);
!   endif
!  
!   # count nr of matrix arguments
!   mvars = 0;
!   while (mvars < nargin) && ismatrix(varargin{mvars+1})
!     mvars++;
!   endwhile
!  
!   if (mvars < 1 || mvars > 3)
!     usage (usage_str);
!   endif
!  
!   ## all except imshow(r,g,b)
!   if (mvars != 3)
!     I = varargin{1};
!     if max(max(varargin{1})) <= 1
!       # image in [0-1]; scale to [0-255]
!       I = I * 255;
!       M = gray(256);
      endif
    endif
 
!   ## imshow(x)
!   if (mvars == 1)
!     ## grayscale image [0-N] -- estimate gray levels
!     N = 2^ceil( log2(max(max(I))) );
!     M = gray(N);
!    
!   ## imshow(x, map) or imshow(x, N)
!   elseif (mvars == 2)
!     M = varargin{2};
!     if isscalar(M)
!       M = gray(M);
!     endif
!    
!   ## imshow(r,g,b)
!   elseif (mvars == 3)
!     r = varargin{1}; g = varargin{2}; b = varargin{3};
!     if max(max([r; g; b])) > 1
!       # normalise to [0-1]
!       r = r/255;
!       g = g/255;
!       b = b/255;
!     endif
!     [I, M] = rgb2ind (r, g, b);
!   endif
!  
!   # check for 'truesize'
!   zoom = [];
!   for i = mvars+1:nargin
!     if isstr(varargin{i}) && strcmp(varargin{i}, 'truesize')
!       zoom = 1;
!     endif
!   endfor
!
!   colormap(M);
!   image (I, zoom);
 
  endfunction
+
+ %!error imshow()                   # no arguments
+ %!error imshow(1,2,3,4,5)          # too many arguments
+ %!error imshow([1], [2], [3], [4]) # too many matrix arguments
+ %!error imshow('image.png')        # filename not accepted as argument
+
+ %!demo
+ %!  imshow( loadimage('default.img') );
+
+ %!demo
+ %!  I = loadimage('default.img');
+ %!  imshow(I, 'truesize')
+
+ %!demo
+ %!  [I, M] = loadimage('default.img');
+ %!  imshow(I, M);
Reply | Threaded
Open this post in threaded view
|

Re: imread image sizing

John W. Eaton-6
On 12-Mar-2004, Stefan van der Walt <[hidden email]> wrote:

| I wrote a patch to fix the zooming a while ago.  Maybe you'd find it useful:
|
| http://www.octave.org/mailing-lists/bug-octave/2004/132
|
| The encoding on that e-mail went horribly wrong, so I attach a version
| here as well.

I applied these changes.

Thanks,

jwe


Reply | Threaded
Open this post in threaded view
|

Cygwin build sensitivity to gcc version

Paul Thomas-10
In reply to this post by JD Cole
I posted the problem with the octave slow-up between gcc-3.2 and gcc-3.2.
The gcc maintainers came back, of course, with the request that octave be
profiled, that the two versions be compared and the a sample code fragment
be written that reproduces the slow-up.  I think that this might be useful
to do anyway, since the sensitivity is occurring exactly where octave
underperforms somewhat.

I am prepared to give profiling a go but will almost certainly need some
help and guidance.  Has anybody any experience of using the -pg option with
gprof?

Paul T


Reply | Threaded
Open this post in threaded view
|

Re: Cygwin build sensitivity to gcc version

Paul Kienzle
I didn't try it on windows, but profiling worked fine on linux.

This was about four years ago, so I don't remember the details,
but it didn't take a whole lot to get it working.

- Paul

On Mar 14, 2004, at 5:01 PM, Paul Thomas wrote:

> I posted the problem with the octave slow-up between gcc-3.2 and
> gcc-3.2.
> The gcc maintainers came back, of course, with the request that octave
> be
> profiled, that the two versions be compared and the a sample code
> fragment
> be written that reproduces the slow-up.  I think that this might be
> useful
> to do anyway, since the sensitivity is occurring exactly where octave
> underperforms somewhat.
>
> I am prepared to give profiling a go but will almost certainly need
> some
> help and guidance.  Has anybody any experience of using the -pg option
> with
> gprof?
>
> Paul T
>