# Picture.open get dPi **URL:** \ **Category:** macOS\ **Created:** [July 16, 2026, 6:05pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617 "2026-07-16T18:05:02Z")\ **Posts on this page:** 13\ **Page:** 1
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 16, 2026, 6:05pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/1 "2026-07-16T18:05:02Z")
Please download the project [Img-Dpi.zip](https://forum.xojo.com/uploads/short-url/zMUfuWzTIKyOZP7eEh8eHtVGYKD.zip) (7.1 KB) and launch it. Drag&drop a Png (or Jpg etc.) on the Canvas or click the button and choose the picture file. On Mac, you will not always have the good dpi displayed in Label2 (I open the same picture file with Preview to compare). It seems that if the picture file has been saved with Xojo (and is 144 dpi), it will display 144 dpi in the label2. But if you select a file saved by another application (the Finder if you made a screencapture, or a picture saved by Preview or by Affinity), it will always display 72 dpi (even if in 144 dpi). I launched my small program on window and all it is ok, the good dpi is displayed. And more strange, if you drag and drop this picture [SmallRedDot@1x.zip](https://forum.xojo.com/uploads/short-url/mtEIGMRIEKnXcag8IOGZvLkFGIw.zip) (2.7 KB) and drag&drop it it, Label2 will display 144 dpi. If you rename it “SmallRedDot” it will display 72 dpi??? ---
**Author:** ![Emile\_Schwarz](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/90ced4/32.png) [@Emile\_Schwarz](https://forum.xojo.com/u/Emile_Schwarz)\ **Post date:** [July 16, 2026, 6:31pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/2 "2026-07-16T18:31:23Z")
With Xojo 2026r1.2, the macOS red dot drag result in 144 dpi. Bug a 96 dpi .jpg file is displayed at 72,72. That file saved at 300 dpi with Preview (and resized at 300 pixels/width gaves: ![image](https://forum.xojo.com/uploads/default/original/3X/5/b/5b79478ee22f9076fe8411e6270c375c355a1dbf.png) NB: I do not looked at the code. I forgot: at your project launch time Xojo told me it was created with a new version AND some objects will be removed (I DO NOT KNOW ANYTHING ABOUT THAT AND I THINK I READ THE RN MORE THAN ONE TIME). ---
**Author:** ![Emile\_Schwarz](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/90ced4/32.png) [@Emile\_Schwarz](https://forum.xojo.com/u/Emile_Schwarz)\ **Post date:** [July 16, 2026, 6:53pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/3 "2026-07-16T18:53:21Z")
The code below returns 300 dpi as I await IN THE DEBUGGER and: ![image](https://forum.xojo.com/uploads/default/original/3X/7/6/76b0381c2342be0d5e2cc2d5e5b00804129694e8.png) ```auto Var TpBckImg As New Picture(300,441) Var TpImg as Picture Var TpImgW, TpImgH as Int16 Var TpCoeff as Double Try TpImg = Picture.Open(f_Elt) Break TpBckImg.HorizontalResolution = 300 TpBckImg.VerticalResolution = 300 Break TpBckImg.Graphics.DrawPicture TpImg,0,0 Break Catch ' @w@a@ #76011 Il faut mettre le Catch ' Impossible de lire l'image TpImg = Nil End Try ``` ---
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 17, 2026, 9:37am UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/4 "2026-07-17T09:37:27Z")
I created an [issue](https://tracker.xojo.com/xojoinc/xojo/-/issues/81650)#81650 . If you download the sample project from the issue (I updated the project I posted here yesterday), I found a workarround, I have to add “@1x” to name of the picture file in order to Xojo read well the dpi. ---
**Author:** ![Emile\_Schwarz](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/90ced4/32.png) [@Emile\_Schwarz](https://forum.xojo.com/u/Emile_Schwarz)\ **Post date:** [July 17, 2026, 10:44am UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/5 "2026-07-17T10:44:56Z")
Three months to wait for 2026r3 if this will be corrected in the near future. In the mean time, you know what to do (even if you forget to tell something in the original post). ---
**Author:** ![Michael\_Hußmann](https://forum.xojo.com/user_avatar/forum.xojo.com/michael_hu%C3%9Fmann/32/438_2.png) [@Michael\_Hußmann](https://forum.xojo.com/u/Michael_Hu%C3%9Fmann)\ **Post date:** [July 17, 2026, 11:48am UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/6 "2026-07-17T11:48:49Z")
> [@Thomas\_ROBISSON](#): > > If you download the sample project from the issue (I updated the project I posted here yesterday), I found a workarround, I have to add “@1x1x1x1x” to name of the picture file in order to Xojo read well the dpi. Well, that’s seriously odd. The resolution is just metadata waiting to be read and the filename should have nothing to do with the result. Let’s hope this will be dealt with soon. Having said that … I’m curious why you even bother to access these values. I have often dealt with picture files in my projects but there has never been a reason to check the resolution. For example, the Exif standard for the metadata written by digital cameras and scanners specifies that the default resolution value for digital photographs should be 72 ppi, regardless of everything else. The resolution value was originally introduced with scanners in mind: When you are scanning a picture you know precisely how many pixels get scanned per inch and the resolution values are actually informative: they allow you to calculate the actual size of some image detail. With digital photographs this quite different because without knowing the distance there is no way to tell how large some subject is, and with subjects at different distances in the same image, each one would have been pictured at a different resolution. Thus the recommendation to write 72 ppi and be done with it. Some cameras allow the photographer to select a different value but this makes no difference whatsoever – the actual image data isn’t affected at all and in any case it doesn’t tell how large anything in the picture actually is. The output resolution is a different topic altogether: In the end it comes down to how many pixels are in the image and how large the picture should eventually appear on the screen, on paper or any other medium; this determines the ppi (pixels per inch) value. The dpi (dots per inch) value, on the other hand, wholly depends on the resolution of the screen, printer or whatever. ---
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 17, 2026, 12:58pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/7 "2026-07-17T12:58:01Z")
I didn’t tell in my first post what was my workarround as I didn’t know it. I explained it in my previous post: If my file’s name is “MyPicture.png” I rename it "“MyPicture@1x.png” before do Picture.open(MyFilePicture). I made my own software to take screencapture, and depending if the guy use a high dpi screen or not I display the dpi. I can also drag&drop a picture on my window app and I display the dpi too. I wrote a small software (I do not distribute) to check all my html files (my website) to check if a write the good size in `“Img”` because I do a lot of copy paste, I modify the picture path but I often forget to write the good width/height. And I need to know the dpi because I set the dpi to the size I want to display the picture. I know that html doesn’t care the dpi but I do. ---
**Author:** ![Emile\_Schwarz](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/90ced4/32.png) [@Emile\_Schwarz](https://forum.xojo.com/u/Emile_Schwarz)\ **Post date:** [July 17, 2026, 2:53pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/8 "2026-07-17T14:53:41Z")
> [@Michael\_Hußmann](#): > > Well, that’s seriously odd. The resolution is just metadata waiting to be read and the filename should have nothing to do with the result. Let’s hope this will be dealt with soon. Obviously, you do not know what @1x, @2x, @3x was implemented for. Drop an image in the Navigation pane and you will start to understand. The idea is to let the OS decide what image to draw depending on the Retina/HDPI screen settings. I tried to found where in the Documentation the description is, but I do not found. Gemini gaves me the URL: > **[Image Set Editor — Xojo documentation](https://documentation.xojo.com/getting_started/using_the_ide/image_set_editor.html)** ---
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 17, 2026, 3:23pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/9 "2026-07-17T15:23:08Z")
@Xx is a conventional use and I’m sure if you drop a file named MyPict@3x on Xojo it will put it in the 3x even if it is 72 dpi. The dpi are metadata inside the file, and as Michael wrote, it as nothing to do with the name. ---
**Author:** ![Michael\_Hußmann](https://forum.xojo.com/user_avatar/forum.xojo.com/michael_hu%C3%9Fmann/32/438_2.png) [@Michael\_Hußmann](https://forum.xojo.com/u/Michael_Hu%C3%9Fmann)\ **Post date:** [July 17, 2026, 3:59pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/10 "2026-07-17T15:59:38Z")
> [@Emile\_Schwarz](#): > > Obviously, you do not know what @1x1x1x1x11x1x1x1x1@3xxx1@3xxxx3@3x1x1x@@@3x3xxxx @3x@3xx, @3x was implemented for. I know. And I also know it hasn’t got anything to do with the resolution as stored in the metadata. That’s why you include this kind of data in the filename. Now maybe the HorizontalResolution and VerticalResolution properties of Picture aren’t actually supposed to mirror the resolution stored in the image file’s metadata but are rather intended to reflect info contained in the filename, only there is nothing in the documentation to suggest that. ---
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 17, 2026, 10:26pm UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/11 "2026-07-17T22:26:59Z")
> [@Michael\_Hußmann](#): > > rather intended to reflect info contained in the filename And in that case the result would be the same under Windows. ---
**Author:** ![Thomas\_ROBISSON](https://forum.xojo.com/user_avatar/forum.xojo.com/thomas_robisson/32/15868_2.png) [@Thomas\_ROBISSON](https://forum.xojo.com/u/Thomas_ROBISSON)\ **Post date:** [July 18, 2026, 8:55am UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/12 "2026-07-18T08:55:42Z")
Another workarround is to read the picture as BinaryStream and do Picture.FromData. `Try` `StreamInBin = BinaryStream.Open(f_Elt, False)` `LgMbBlk = StreamInBin.Length` `CpMmBlk = StreamInBin.Read(LgMbBlk)` `StreamInBin.Close` `TpImgG = Picture.FromData(CpMmBlk)` `Catch ’ @w@a@ #76011 Il faut mettre le Catch ’ Impossible de lire l’image` `CpMmBlk = Nil ’ Y est déjà` `TpImgG = Nil ’ Des fois qu’un truc ait été mis dedans ???` `End Try` [Img-Dpi.zip](https://forum.xojo.com/uploads/short-url/8wZYxiHfLnE5uZRXSYgAN0FMZy4.zip) (628.5 KB) ---
**Author:** ![Emile\_Schwarz](https://forum.xojo.com/letter_avatar_proxy/v4/letter/e/90ced4/32.png) [@Emile\_Schwarz](https://forum.xojo.com/u/Emile_Schwarz)\ **Post date:** [July 18, 2026, 9:49am UTC](https://forum.xojo.com/t/picture-open-get-dpi/88617/13 "2026-07-18T09:49:14Z")
You may read this: [HiDPI support](https://documentation.xojo.com/topics/graphics/hidpi_support.html), especially the table below the **Image** entry. There are information related to your question. ![image](https://forum.xojo.com/uploads/default/original/3X/b/a/ba7c975968a53137cebbf675462ccd8734953b22.png) Look at the _Depths_ entry… Things are more complex than what it seems… Check `Picture.Type` to choose between these four types: **MutableBitmap** , **ImmutableBitmap** , **Image** , and **Vector** Alphabetizing things, sometimes is stupid; look at **HorizontalResolution** and **VerticalResolution**. Same Apply with **Height** and **Width** and maybe others. This could be resolved with _API II_ using _ResolutionHorizontal_ and _ResolutionVertictal_…