High dpi images.

With a scanner, you’re doing it the other way around and you will actually get images of different pixel sizes.
If you read what I wrote to you above, I’m pretty sure the subject will get clearer for you.

Within Xojo, it’s really not that hard. There are just 2 ways to do things. Either let Xojo handle it for you or do things yourself.

Thank you Marco.

That is exactly what I wanted.

Changing the DPI value in a software is not secure if you do not check if the resulting file size have changed too.

Now, I will re-read your post Marco (I have a downoad to wait 'till it is done…).

Marco: say I’m OK with what you wrote. The trouble comes with Xojo. I may forgot something.

FWIW, the image sizes are:

72 dpi: 71,801Bytes 96dpi: 141,882Bytes 300dpi: 1,393,126Bytes

Without doing anything to the project (you can check at it) When I load and display these images, I get three different sizes. Must I set something regarding a “Retine /HiDPI” in the project ?

I ask just to be sure what I have in mind = what the reality is (and eventually update what’s in memory).

Yes. Under Shared Settings, you need to turn Supports Retina/HiDPI on. Then I suspect you’ll get what you are expecting.

Keep in mind that for maximum efficiency, you should combine these into an Image. That way the Framework should select the best version of the image for the current drawing conditions.

That is the only possible explanation (I was hoping…)

Thank you.

Just to confirm what I thought the confusion might be, in Photoshop when you create a new image, check the selector next to “Width:” & “Height:”.

When it’s set to “Pixels”, the DPI doesn’t alter the amount of pixels in the image, so 200 x 200 @ 300 dpi has the same pixels as 200 x 200 @ 72 dpi. However when Photoshop is set to anything else, it increases the volume of pixels to meet the dpi.

So by switching it to “Points” I get the following.

  • 200 x 200 @ 72 dpi = 200 x 200 pixels.
  • 200 x 200 @ 144 dpi = 400 x 400 pixels.
  • 200 x 200 @ 300 dpi = 833 x 833 pixels.

Hope that this helps clear up the confusion.

That’s what I was thinking but if you look at the drawing code…

g.drawpicture CodeSnippets,(me.width - CodeSnippets.width)/2,(me.height - CodeSnippets.height)/2,CodeSnippets.width,CodeSnippets.height,0,0,CodeSnippets.width,CodeSnippets.height

…that’s always drawn at 72 dpi, as pointed out by Michel. The DrawPicture basically ignores any dpi of the Picture.

So … when I draw in a Canvas then the coordinates are Points now, not Pixels, if I got this right?

So if I draw a line from 10,10 to 100,100 at LineThickness 1 then that is

from Point 10,10 aka Pixel 10,10 on non-Retina or Pixel 20,20 on Retina
to Point 100,100 aka Pixel 100,100 on non-Retina or Pixel 200,200 on Retina
at Thickness 1 Point aka 1 Pixel on non-Retina or 2 Pixel Retina?

How do you draw finer then?

Correct.

In native Xojo, you can adjust the scale of the graphics so you can draw thinner.

I see in the new framework they’re using doubles for geometry, where in the past they used integers, so I suspect that you can also do with the new framework.

On OS X, you can of course use Core Graphics via declares or plugins. Which take floats, so you can get line thickness of less than 1.0.

Sam,
my photoshop image was created with it set to pixels, not points.

[quote=269324:@Richard Summers]Sam,
my photoshop image was created with it set to pixels, not points.[/quote]

What you don’t get is in order not to break existing code, Xojo’s HiDPI mode programs draw at 72 points no matter what. So you can have a 1200 pixels per inch picture and if you scale it like you do, it will still draw at 72 dpi, like it used to before HiPDI.

I have been trying to tell for two days now :confused:

You (and probably some other participants as well) really want to read carefully the HiDPISupport.pdf document in documentation next to your Xojo executable.

In particular the paragraph about Graphics, ScaleX and ScaleY.

I never said my image was being displayed at 300dpi.
I said the 300dpi image which I dragged into the navigator, looks perfectly crisp on both retina and non-retina.

I have been trying to tell you that for 2 days now :slight_smile:

:stuck_out_tongue:

I looked in the Developer area and unless I missed it, this sure looks like a sure-fire candidate for a webinar.

Mac handles retina really well. But all my high-dpi images look like dog poop on Windows.

If your image is to be displayed at 200x200, why not just have the one image at 600x600 (except in the case of icons as @Greg O’Lone mentioned above)? Still not clear on this.

Because scaling an image from 600x600 down to 200x200 will give you crappy looking results as pixels are combined when you scale the image down (or if you have a 200x200 and scale it up to 600x600 you get the opposite effect)
The less scaling / stretching that has to be done the better the results will look

Here’s a few docs on Apple’s reasons why you should not do this
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Optimizing/Optimizing.html
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Explained/Explained.html

If your application is resizable and your canvases stretch with the window, isn’t it impossible to avoid this though? In my apps I force them to stretch to the correct aspect ratio but deliberately include massive images to compensate for the possibility of 5K screens.

To some degree you cant avoid some stretching if your controls stretch to fit and have images
What you CAN avoid is starting out by having to stretch / scale from the outset then having to compound that by stretching / scaling more as the control resizes as well

[quote=269453:@Norman Palardy]Because scaling an image from 600x600 down to 200x200 will give you crappy looking results as pixels are combined when you scale the image down (or if you have a 200x200 and scale it up to 600x600 you get the opposite effect)
The less scaling / stretching that has to be done the better the results will look[/quote]
Also 600 x 600 is currently overkill, it’s wasting memory and processing time. UNTIL 3x screens appear, 400 x 400 is the most needed, anything over and it’s simply being inefficient.

If you can use vector, you may want to do so. The MacOS supports PDF vector images ‘out of the box’, these can easily be scaled without loss of resolution and the OS employs some clever caching so they take minimal time to draw on screen.

You may also want to consider using some xojo graphics or core graphics primitives to draw some elements, leaving only the most complex drawing as bitmaps. Core Graphics has beautiful gradients and drop shadows, also a clippable context (to any shape you want).

Apple’s AppKit also has functions for stretching images, think drawing a button in photoshop and then getting the AppKit to stretch only the middle of the image, keeping the ends as you designed them. Can be done with 3 or 9 parts.

Lastly, if you’re insistent on using a single image instead of multiple representations (heck there are scenarios where this is preferable). Consider using 0.4 compression on jpegs or J2K (better compression and transparency support) or a tool like ICNSmini to overcompress PNGs or smartly compress TIFF images.

You know, that discussion about images reminds me very much of what happens in Web design. There are people who use much too big pictures and then their site crawls.

Picture optimization is a big part of performances.