imresize and ImageJ

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

imresize and ImageJ

ijourneaux
I am trying to understand some differences in the results between ImageJ and Octave when resizing an image

In imageJ If I start with a gray scale image that is 4000x1200 pixels and scale it down to 1000x300  then down to 250x75. The default for ImageJ are bilinear.

If I repeat the same steps in Octave, i.e. imresize(a, .25, linear) the std deviations are not what I would have expected.
Here are the stdev
                     ImageJ       Octave
4000x1200      4.694          4.694          
1000x300        3.253          4.711
250x75           2.007          4.555

The drop in std dev seen in ImageJ seem to be what I would have expected. With Octave, the fact that the std dev actaully increased in the first resize operation seems particularly odd.

Perhaps I am misinterpreting what imresize is supposed to do in Octave? Appreciate any thoughts.
Reply | Threaded
Open this post in threaded view
|

Re: imresize and ImageJ

James Sherman



On Tue, Aug 19, 2014 at 12:36 PM, ijourneaux <[hidden email]> wrote:
I am trying to understand some differences in the results between ImageJ and
Octave when resizing an image

In imageJ If I start with a gray scale image that is 4000x1200 pixels and
scale it down to 1000x300  then down to 250x75. The default for ImageJ are
bilinear.

If I repeat the same steps in Octave, i.e. imresize(a, .25, linear) the std
deviations are not what I would have expected.
Here are the stdev
                     ImageJ       Octave
4000x1200      4.694          4.694
1000x300        3.253          4.711
250x75           2.007          4.555

The drop in std dev seen in ImageJ seem to be what I would have expected.
With Octave, the fact that the std dev actaully increased in the first
resize operation seems particularly odd.

Perhaps I am misinterpreting what imresize is supposed to do in Octave?
Appreciate any thoughts.



--
View this message in context: http://octave.1599824.n4.nabble.com/imresize-and-ImageJ-tp4666125.html
Sent from the Octave - General mailing list archive at Nabble.com.

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave

I'm not familiar with ImageJ, but when you're shrinking an image by a particular factor (in this case by 4) that is an evenly divisible by the size of the image, then you should just end up with a straightforward subsampled image, no interpolation needed.  For a toy example, take a simple 16x16 image:

> rampim = uint8(reshape(0:255,[16 16]));
> smallim = imresize(rampim, .25);

and then compare smallim to a simple subsampling:

> rampim(1:5:end, 1:5:end)

From my work in image processing, I believe this to be the standard behavior and I'm not sure what ImageJ is doing in this scenario.  You could try a comparison with increasing the size of the image or resizing by a factor that isn't evenly divisible by the image size, but wouldn't a better comparison be by looking at the images themselves?

James Sherman




_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: imresize and ImageJ

Stillwater
This post was updated on .
The factor 4 downsampling could be by taking each fourth pixel and the stdev could go up or down a bit. In medical images, downsampling is usually done by averaging the 4x4 neighborhouds; the stdev goes down, and so does the noise.
Reply | Threaded
Open this post in threaded view
|

Re: imresize and ImageJ

ijourneaux
I am surprised that the std dev could go up significantly when down sampling by a integer factor. Perhaps I am just not understanding the goal of imresize and interp2. I would have expected the desired output for each pixel to be the best estimate of the new pixel location. It would seem to me that this should almost always result in the std dev dropping.

Ian
Reply | Threaded
Open this post in threaded view
|

Re: imresize and ImageJ

James Sherman



On Tue, Aug 19, 2014 at 8:28 PM, ijourneaux <[hidden email]> wrote:
I am surprised that the std dev could go up significantly when down sampling
by a integer factor. Perhaps I am just not understanding the goal of
imresize and interp2. I would have expected the desired output for each
pixel to be the best estimate of the new pixel location. It would seem to me
that this should almost always result in the std dev dropping.

Ian



--
View this message in context: http://octave.1599824.n4.nabble.com/imresize-and-ImageJ-tp4666125p4666133.html
Sent from the Octave - General mailing list archive at Nabble.com.

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave

Eventually, as you interpolate more and more, the std would be expected to go down because you're essentially smoothing out the data more and more, but there is certainly no guarantee in the interim.  Its the same reason that if you have n numbers and then select every 3rd number there's nothing to guarantee that the standard deviation is the same.

As far as the purpose of imresize and interp2, you're right it is to get the best estimate of the pixel value at that position, but this has no direct relation to standard deviation.  This occurs the same in the 1-D case.  Say that your original image is 10 "pixels" long, located at the the integer locations 0 through 9 with just some random values:
position: 0 1 2 3 4 5 6 7 8 9
value: 5 5 7 8 9 2 4 3 3 2

Now, if you wanted to resize your image to only have 4 pixels, one way (using interpolation) is that imagine that the "true" image is still exists from 0 to 9, but since you only have 4 pixels, the pixels are now at the positions 0, 3, 6, and 9 (equally spaced between 0 and 9) .  So now, how do you fill in those pixels?  Well, the best estimates for the values at positions 0, 3, 6 and 9?  Since these values are already "known" from the original image, the best values are just those original values.   On the other hand, if you wanted to resize down to only 3 pixels, you'd want to estimate the positions at 0, 4.5 and 9.  Well again, 0 and 9 are already "known" from the original image, but 4.5 is not, so thus one must have a way to interpolate using close by pixels.  The specific value is determined by the choice of interpolating function.

This does have drawbacks (particularly when downsizing), and one way to avoid some artifacts is to run the image through a lowpass filter (such as an averaging filter such as Stillwater described) before doing the resizing.  This in essence tries to calculate the average or "best" value representing a region of the original image, and not just at a particular point.

Hope this helps.

_______________________________________________
Help-octave mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/help-octave
Reply | Threaded
Open this post in threaded view
|

Re: imresize and ImageJ

ijourneaux
I completely agree with everyones comments wrt the impact on std dev. I wish I could easily share a copy of the image I am working with. Visually the images look ok but if you zoom in to the pixel level, the imresize image has a lot of artifacts that ImageJ does not. If I get a chance, I am going to try installing Matlab and look at what Imresize does there

Here is what I am trying to do; I have a scanned in image 1200 dpi image that I would like to reduce to 96dpi and approximate the output of a scanner if the image was scanned at 96dpi.

The averaging filter probably accomplishes that.