How to turn pixel values to mm on axes

Hello

As far as I know, Matlab plots give X,Y in pixel values. How do I turn them to units of length? E.g. milimeters? mm. I want X,Y values to appear as mm.

Thanks

[Stelios Fanourakis]

For instance, how do I make X,Y appear as mm and not pixels, see the image.

[Stephen23]

"As far as I know, Matlab plots give X,Y in pixel values"

Can you give a link to the documentation where this is stated?

Answer 1

[Totanly]

first find, how many pixels =1mm?

suppose10 pixel=1mm;

X_in_mm=X./10;
Y_in_mm=y./10;
xlabel('x in mm')
ylabel('y in mm')

[madhan ravi]

Selec the code and press the code button so that the code is easily distinguished.

[Stelios Fanourakis]

1 mm of length corresponds to 1.09 pixels. I use that script. Is it correct how stated? I don't see much of difference.

figure
X=X./1.09;
Y=Y./1.09;
A=contour(mask,'b')
set(gca,'ydir','reverse',X,Y)

[Stephen23]

@Stelios Fanourakis: read Walter Roberson's answer, it gives a very brief outline of what you will need to consider. You approach is far too simplistic, and is based on incorrect assumptions (i.e. "As far as I know, Matlab plots give X,Y in pixel values").

Answer 2

[Walter Roberson]

No, all graphics that takes place within an axes is in data units, not in pixels. Your label of 300 in your example is 300 data units, not 300 pixels. If you were to resize the axis the labels would move proportionately but would not change.

If 10 of your input units are intended to represent 1 mm, then you can plot(X./10, Y./10) . Note that this will just change the effective labels (and data cursor information) but will not change the fact that these will be data units, and that they will take more or less screen space depending how you resize your axis.

If you need 10 data units to correspond to 1 real-world mm (so like you could put a ruler up against the screen and measure it as 1 mm) then you need to set the Axes Units property and you need to be careful about your xlim and ylim and data aspect specification.

But even if you get those all right in theory, in practice they will likely be wrong unless you are working with a high quality calibrated display. Most displays report nominal resolution, but if you go to an "Office Supply" store that sells monitors and you compare two monitors with different screen sizes but the same number of pixels, you will often find that they both report the same nominal resolution. The user controls given on monitors also affect the real-world resolution, and not necessarily linearly. (CRT are subject to pincushion and barreling for example.)

[Walter Roberson]

Do you need each change of 1 data unit to correspond to a change 1 mm on the physical screen? Should your 650 data units across correspond to 650 mm, roughly 25.6 physical inches?

[Stelios Fanourakis]

I wasn't aware of data units. All I know is that 1.09 pixels corresponds to 1 mm.

I want the axes to have mm. Any idea? Thanks

[Stephen23]

"I want the axes to have mm. Any idea? Thanks"

Probably you can just change the axes labels and/or tick marks. Note that this is entirely unrelated to pixels, which possibly is just some random misinformation that you put in your question title just to confuse everyone and delay getting an answer:

http://xyproblem.info/

So please clarify this for us, which of these you want to do?:

1. label your axes with mm.
2. scale the axes so that the data have a fixed, known size on your screen?

[Stelios Fanourakis]

What units are the Data Units if not pixels? I always had in mind that there are pixels. I know a lot of my colleagues that pronounce them as pixels.

I want to label my axes with mm and a step size of 1 mm, if possible.

[Stephen23]

"What units are the Data Units if not pixels? I always had in mind that there are pixels. I know a lot of my colleagues that pronounce them as pixels. "

Read Walter Roberson's answer:

https://www.mathworks.com/matlabcentral/answers/438800-how-to-turn-pixel-values-to-mm-on-axes#answer_355572

Data units are data units. They do not have a fixed correspondence to pixels, millimeters, fathoms, lightyears, ångströms, potrzebies or any other fixed length unit. Your colleagues might be refering to something related to images (which are often measured in pixels), but even these are unlikely to correspond to actual pixels on any modern LCD screen. In any case your question refers to "plots" and not images.

"I want to label my axes with mm and a step size of 1 mm, if possible."

You should have asked that ten hours ago.

http://xyproblem.info/

[Walter Roberson]

Your diagram appears to show x axis up to 650 starting from 50. If each of those (650-50) is intended to be one pixel, and 1.09 pixels is 1 mm, then

>> 600/1.09/25.4
ans =
          21.6716029762335

so you would be wanting an output which was 21.67 inches wide (excluding the white border). Is that what you need?

Or do you want your existing diagram to be relabled so that however many pixels it is using right now should be relabeled in mm ? When I open your attached image in my browser, the part inside the axes corresponds to almost exactly 10 cm. So would you like the image size to remain unchanged, but the labels at the bottom to be changed from being 50:50:650 into being 10:10:100 and add xlabel('mm') ? And if you were to grab the figure and resize it, you would like it to automatically relabel according to the new axis physical axis width?

1.09 pixels per mm would, by the way, correspond to 27.686 dots per inch. My calculation is that that would correspond roughly to NTSC television resolution on a 20" diagonal TV screen... not very good at all. Are you trying to display MATLAB graphics onto television quality monitors, such as in an older train station? And yet for some reason it is important that the labels accurate state mm ??

[Stelios Fanourakis]

@Walter Roberson.

No, it is just for research purposes and I want to display them in a normal PC screen.

I enclose my results so far.

I would like to begin with 0 and have a step of every 1 mm, up until the end. The contour shape should be around 70 mm in width and 10 mm in Height.

[Stelios Fanourakis]

Remember that for calibration reasons I use this code

Where for every screen pixel corresponds 0.9183 mm of real world units of length.

Or for every 1mm of real world units corresponds 1.09 pixels of the screen. Does it make any sense?

    conversion=0.9183; % in mm/pixel
    addMM=@(x) sprintf('%.3fmm',x*conversion);
    xticklabels(cellfun(addMM,num2cell(xticks'),'UniformOutput',false));
    yticklabels(cellfun(addMM,num2cell(yticks'),'UniformOutput',false));

[Stelios Fanourakis]

How do I modify the range and the step at the above piece of code?

[Stelios Fanourakis]

After some consideration I came up with that result (see image I enclose).

Although, I fixed the step to alter every 1 mm still it isn't correct. The 0 point is not at the beggining of the axes and the contour is not correct. The contour should be around 70 mm in length, but the image shows around 5 mm. I used the xticks command from 0 to 100.

What is wrong?

That's what I used.

xticks =([0:1:100])
yticks =([0:1:100])

    conversion=0.9183; % in mm/pixel
    addMM=@(x) sprintf('%.3fmm',x*conversion);
    xticklabels(cellfun(addMM,num2cell(xticks'),'UniformOutput',false));
    yticklabels(cellfun(addMM,num2cell(yticks'),'UniformOutput',false));

[Stephen23]

"Although, I fixed the step to alter every 1 mm still it isn't correct."

Axes tick mark locations are specified in the axes' data units, and have nothing to do with millimeters, inches, or lightyears. In any case, you did not set the tick mark locations (i.e. using the function xticks or yticks), you only changed the tick mark labels.

Although you created (badly named) vectors with a step of 1, you then multiplied those vectors by 0.9183, so of course you will not get a step of 1 in the tick labels. Do you expect 1*0.9183 ==1 ?

"The 0 point is not at the beggining of the axes..."

You will need to change the axes limits (like everything else in the axes the axes limits are in data units and not in pixels, millimeters, yards, furlongs, or chains).

"The contour should be around 70 mm in length,"

Do you expect that shape to be 70mm long on your screen? I don't see anything in your code that measures the actual screen resolution and resizes the axes to get that size on screen.

"I used the xticks command from 0 to 100."

Your code does not show that anywhere. Actually you named some variables xticks and yticks, which means that you will not be able to use the tick functions at all (which is why I wrote that they are badly named).

You seem to be stuck on this idea that plotting corresponds to pixels/millimeters/whatever and by changing the labels you will get a particular size image on your screen. It really is not that simple. Start by reading Walter Roberson's answer, then reading these:

https://www.mathworks.com/matlabcentral/answers/100792-in-matlab-how-do-i-obtain-information-about-my-screen-resolution-and-screen-size

https://www.mathworks.com/help/matlab/ref/matlab.graphics.axis.axes-properties.html

[Walter Roberson]

For comparison, when I open your second.jpg on my desktop in Firefox, the portion of the image inside the axes box is almost exactly 100 mm wide, and the horizontal width of the shape is 64 mm.

On my laptop, again in Firefox, the portion of the image inside the axes box is 84 mm, and the horizontal width of the shape is 54 mm.

Oh, but then I grabbed my desktop browser window and resized it down as far as it would go, and the axes box shrank to 60 mm wide and the horizontal width of the shape shrank to 38 mm.

Which of these behaviours are you looking for:

1. If the user tries to drag to resize the figure window after the plot is drawn, the user should be refused. Everything about the figure window should be locked to a particular size ? Or
2. If the user tries to drag to resize the figure window after the plot is drawn, the user should be permitted to do that, but the axes should stay exactly the same physical size, with greater or lesser whitespace around the axes, and the drawing being visually truncated if the figure window is made too small? Or
3. If the user tries to drag the resize the figure window after the plot is drawn, the user should be permitted to do that, and everything about the plot should visually scale itself proportionately, without any change to the content of the plot? Or
4. If the user tries to drag the resize the figure window after the plot is drawn, the user should be permitted to do that, and the lines on the plot should visually sale proportionately, but the xticks/yticks and data cursor information should be updated to reflect physical screen measurements -- so for example if the user made the window 50% wider and the same height, that the shape should become 50% wider on-screen and the corresponding label positions would become 50% further apart, but the labels 10, 20, 30 should become 15, 30, 45 reflecting the ruler-measurable distances on the screen?

Where for every screen pixel corresponds 0.9183 mm of real world units of length.

You say that you want to display on a "normal PC screen".

Does your experience go back as far as the DEC VT52 terminals of the 1970s? According to http://bitsavers.informatik.uni-stuttgart.de/pdf/dec/terminal/vt52/EK-VT52-MM-002_maint_Jul78.pdf which is an official maintenance manual, even back then each screen pixel corresponded to no more than 0.389 mm. I have been unable to find any time in the history of PCs when a "normal PC screen" would have had a resolution as low as 0.9183 mm per pixel. Not even VGA was that low of a resolution.

[Stelios Fanourakis]

@Walter. Well using a calibration tool, I found that a distance of 400 mm in the image include 435.6 pixels. That makes us 1.09 pixel per 1 mm of unit length. Am I correct? Can you also please check my new question?

I slightly changed my objective

[Walter Roberson]

Please run the attached code and post the results.

On my system the result is

A 15" screen is about 380mm diagonal
A 17" screen is about 430mm diagonal
A 21" screen is about 530mm diagonal
A 27" screen is about 680mm diagonal
What is the physical measurement of the diagonal of your display, in mm ? 680

graphics thinks image size is x=1366 pixels, y=651 pixels
graphics thinks image size is x=481.894 mm, y=229.658 mm
figure estimates pixels/mm as x=2.83465, y=2.83465
actual image size is x=1366 pixels, y=651 pixels

Hardware screen size is x=1 pixels, y=1 pixels
Hardware screen size is x=2560 pixels, y=1440 pixels
Graphics subsystem "official" pixels per mm is: 2.83465
Physical pixels per mm is about: 4.31943
Ratio of physical pixels per mm to "official" pixels per mm is about: 1.5238
hardware estimate of physical image size is x=316.246mm, y=150.714mm

The difference between physical pixels and "official" pixels has to do with the treatment of High DPI displays. In recent versions of MATLAB, on Mac there are officially 72 pixels per inch, and on Windows there are officially 96 pixels per inch under some circumstances; see https://www.mathworks.com/help/matlab/creating_guis/dpi-aware-behavior-in-matlab.html .

Notice that the physical pixels per mm for my display is over 4 times your claim of about 1.09 .

The physical measurement of the images was 315 mm by 152 mm (measured with a tape measure) -- in agreement with the hardware estimated image size and not what the graphics system would suggest the size would be.

Thus, the physical output size is best calculated as number of image pixels divided by physical pixels per mm. Unfortunately you may need the user input about the physical screen size in order to calculate this.

[Stephen23]

"Well using a calibration tool,..."

Measuring what exactly:

1. something displayed on a particular screen, or
2. data stored in an image file, or
3. ...something else?

"I found that a distance of 400 mm in the image include 435.6 pixels"

That pixel density might match an old B+W TV. Unusual, to say the least... unless of course you were actually just measuring an image displayed on your screen at some arbitrary scaling (so that the image pixels do not have a one-to-one correspondence with the screen pixels, as is almost always the case these days). If that were the case you would still need to get/measure the screen pixel density and use the factor based on that "calibration" measurement.