size of image

readImage1=imread(image_file1);

[x1,y1,z1] = size(readImage1);

what does mean by the second line of the code ?

[nabeel raza]

the readImage1 size will be assigned to x1,y1,z1; that would be 512*512*3

[Image Analyst]

Those numbers are not necessarily the size of her image. The numbers could be anything - depends on the image.

Make sure you read my answer below as to why that code is wrong, and why the accepted answer from Jorge is also wrong even though she accepted it. It's a common beginner mistake.

Answer 1

[Jorge]

Hi! The second line of the code assigns the size of the image to three variables, namely x1, y1 and z1. If the image 'image_file1' is an image stack, that is, more than one image stored in 'layers' (so to speak) or a 3-D image consisting of 3D units called voxels (ex. tomography), then z1 will be greater than 1. Otherwise, in the case of a common 2d image, only x1 and y1 will be greater than 1; and x1,y1 will account for the width and height of the picture given in pixels.

[Image Analyst]

"x1,y1 will account for the width and height" - not exactly true. x1 and y1 are the height and width (not width and height ), respectively, because the programmer messed up with the placement or naming of the variables as I explained in my answer.

[burges]

Hi, i have a little confusion with this. Maybe you can clear my doubts. If after reading the image with imread() one decides to flip the image using flipud() so as to convert to Cartesian coordinates, does the call to size of the image still hold as:

[row, col, page] = size(readImage1)

Does it not become:

[col, row, page] = size(readImage1)

Thank you.

[Image Analyst]

No it does not. Doing a vertical or horizontal flip will not change the number of rows or columns. Just think about it. However doing a transpose will swap those values.

[Jeremy Ruth]

I'd just like to add for those looking into this later that the programmers did NOT make a mistake with the seemingly backwards row and col. It is intentional because images use a different axis notation. The 0,0 point is at the top left of the image, not the bottom left. This means that the x-axis for an image is actually the vertical axis, and the y-axis is actually the horizontal axis. Programs like Photoshop and most other professional graphic design programs also use this rotated formatting for the axis, and your computer monitor even references pixels via a rotated axis like this as well if I am not mistaken. Draw and label a regular x and y axis on a piece of paper, label the 0,0 point, and flip it 90 degrees to get the idea.

[Image Analyst]

Jeremy, I'm not buying it. Photoshop is consistent with MATLAB and other programs. I just went into Photoshop to verify that. If you bring up the info window (F8) and mouse around, you'll see that the x is the horizontal (column) direction, just like MATLAB, and the y is the vertical (line, row) direction with y=0 (or 1) at the top line, just like MATLAB and the convention in everything else I've seen.

As far as monitors go, I don't see anywhere in Windows 10 where it says x is the vertical direction, see the Windows 10 API and you can see from this code example for the Windows API that when they move the arrow right or left the x value, not the y value, gets changed indicating that Windows definitely considers x the horizontal direction and y the vertical direction.

Sure, the y is flipped (1 at top for images, and 0 at bottom for graphs) as is the convention, but y is still the vertical direction. And x is still the horizontal direction with the 0 point always at the left for images and graphs.

Answer 2

[Image Analyst]

It gives the rows in x1 and columns in y1, and either the number of slices in a 3D volumetric image, or color channels in a color image.

Calling rows x1 and columns y1 is kind of backwards to the usual convention of having the vertical direction be y and the horizontal direction be x. So it should be

[y1,x1,z1] = size(readImage1);

to go along with the standard convention.

For a thorough discussion, see Steve's blog: http://blogs.mathworks.com/steve/2011/03/22/too-much-information-about-the-size-function/