I'm Confused over Screen/Monitor Resolution lazarus / 39-Graphics ---------------------------------------------------------------------- J-G · 2022-08-21 17:28 My current project involves very precise measurement, specifically with regard to physically printed output, but I would also like the display on screen to be as accurate as possible. I've long known that the reported PPI for modern Screens/Monitors is 96 - and the manual for my Ilyama ProLite B1980 confirms that - HOWEVER - (and here is my confusion)  the physical width of the display is 14.81575" and in that distance there are 1280 px - - - - a simple calculation of 1280 / 14.8  results in 86.39456 ??? I also see from the manual that the pixel pitch is 0.294mm (both V &H). Taking this figure and dividing 25.4 by it results in the same figure. The reason I started to investigate this was because a panel which I'd specified at 800px Sq. appears on screen at 234mm Sq. (9.213") when at 96ppi I would expect it to be 8.333".  ie. that confirms that it is displaying at 86.xxx ppi  not 96. Interogating the [Screen] property (X := Screen.PixelsPerInch)  returns 96. This isn't a 'deal-breaker' of course but does seem peculiar (to me) so I'm curious to know if anyone else has had reason to question the 96ppi figure.  I'm not (yet) concerned with the option to display at 125% or 150% via the Windows [Display] facility. The really important figure is the printer dpi and I've already fathomed out how to handle that and can print an accurate scale over 200mm long - though I'm sure each make/model of printer could be different so a calibration routine may well be needed. Two Brother printers I have do agree to within 0.1mm over the 200mm though and that's as close as I can physically measure. ---------------------------------------------------------------------- HeavyUser · 2022-08-21 18:36 Pixels Per Square Inch (PPI) Formula: Diagonal Pixels = Square root of (Vertical Pixels² + Horizontal Pixels²) PPI = Diagonal Pixels / diagonal inches ---------------------------------------------------------------------- J-G · 2022-08-21 19:18 Quote from: HeavyUser on August 21, 2022, 08:36:55 pmPixels Per Square Inch (PPI) Formula: Diagonal Pixels = Square root of (Vertical Pixels² + Horizontal Pixels²) PPI = Diagonal Pixels / diagonal inchesThanks for your input but that suggestion still doesn't resolve the issue  -  it gives the same figure. Also it's PPI not PPSI   (96 PPI would be 9216 PPSI)    but ignoring that minor distinction :- Sq.Rt (12802 + 10242 )  =  1639.2  =  Diagonal Px Sq.Rt (376.322 + 301.0562)  =  481.9247mm  =  18.97342" = Diagonal Inches 1639.2 / 18.97342  =  86.39456. ---------------------------------------------------------------------- MarkMLl · 2022-08-21 20:16 I would suggest that before anything else you look for a utility for your OS of choice which reports what DPI value the monitor is reporting to the graphics card... I think the magic incantation involves DDC and EDID. If an accurate DPI isn't getting as far as the graphics APIs then you're SOL and will have to either prompt the user for a value or have a cross-reference from the monitor product name- assuming that's accurate- and the actual DPI. MarkMLl ---------------------------------------------------------------------- wp · 2022-08-21 20:35 Open the site of your favourite electronics vendor and search for 24" monitors. The site will probably show that they are full HD with 1080 px vertically. Now search for 22" monitors - again they will have 1080 px vertically. I am very sure that Windows will run these two types at 96ppi, although the real pixel density will be different by roughly 10%. I am convinced that the ppi value is just a semi-quantitative number since its exact value depends on the physical size of the monitor. ---------------------------------------------------------------------- J-G · 2022-08-21 22:41 I hadn't previously questioned the 96ppi figure, though I had noticed that when I selected 100% scale in WordPerfect, the page shown was wider than A4 (210mm)  -  I've just made that 90% which is as close as I can get to 89.9943% which is what 86.xxx/96 is and it is 210mm wide. Another Monitor I have is a BenQ DL2215-B (1920 x 1080), the specification on that tells me that the pixel size is 0.01" which is effectively 100ppi, but further research on the BenQ site which reports that their 23.8" Monitor is 93ppi which equates to a pixel size of 0.010753" (0.2731mm) so I suspect that the DL2215 is the same. I don't currently have FPC/Laz on the PC with the BenQ Monitor so can't quickly check what PPI that reports but I suspect that it will be 96. What now excercises me is why Screen.pixelperInch returns 96 rather than 86. Thanks for the suggestion MarkMLI but I have no idea what DDC, EDID mean - nor for that matter what SOL stands for? ---------------------------------------------------------------------- MarkMLl · 2022-08-22 07:02 Quote from: J-G on August 22, 2022, 12:41:14 amThanks for the suggestion MarkMLI but I have no idea what DDC, EDID mean - nor for that matter what SOL stands for? https://en.wikipedia.org/wiki/Display_Data_Channel https://en.wikipedia.org/wiki/EDID The problem is that while display panels have significant value, the controller is just a bit of commodity electronics with an ARM and a standard interface. If the controller's EDID hasn't been set up for the specific panel, then you're Seriously Out of Luck. MarkMLl ---------------------------------------------------------------------- J-G · 2022-08-22 08:33 Thanks for that explanation - and Links - Mark.  As you will now understand I have no 'street cred' as far as Acronyms (or capital abbreviations) are concerned. It has never occured to me to even look into how the PPI of a monitor is determined - the pure practical purpose of wanting to display an image at a specific size is the first time that it became relevant. Being an engineer I suppose that it ought to have been higher on my list of 'need to knows' but Hey Ho. Having glanced through both Wiki pages I am a (very) little wiser but I doubt that I'll really need to become proficient in such matters so am unlikely to study much further. What I have learned from begging this question is that it may well be useful to interogate the user with regard to the specific physical properties of their display so that I can scale accordingly. The calibration of the printer is a much more important aspect, and I've already sorted that. ---------------------------------------------------------------------- MarkMLl · 2022-08-22 09:10 This was driven home a few weeks ago when I came across an otherwise- unremarkable Hackaday article discussing how easy it was to replace a blown electronics board: they're basically a small Linux computer with a low-level display controller and an interface to the LCD panel, hence are to a large extent a commodity part. I've had to dive into the EDID stuff in some depth in the context of a Raspberry Pi, where there is a "backdoor" interface between the main OS and the OS on the display controller to get the parameters. I looked at DDC /years/ ago and one was very much at the mercy of display drivers etc., I can't remember whether there was ever a BIOS extension to drive it. You can, by and large, get the pixel count (X * Y) of the display panel. You can, by and large, get the monitor model name. I'd suggest that the best you can do is find a table which cross-references model name (subject to misspellings :-) with panel size, and /suggest/ this to the user... but ask for confirmation or override before relying on it for DPI. MarkMLl ---------------------------------------------------------------------- PascalDragon · 2022-08-22 11:36 Quote from: MarkMLl on August 22, 2022, 11:10:44 amI've had to dive into the EDID stuff in some depth in the context of a Raspberry Pi, where there is a "backdoor" interface between the main OS and the OS on the display controller to get the parameters. I looked at DDC /years/ ago and one was very much at the mercy of display drivers etc., I can't remember whether there was ever a BIOS extension to drive it. At least on x86 systems DDC can be accessed using VESA BIOS extensions which we use with our operating system at work (though sometimes it depends on the card or even the used port; e.g. we have a card at work where VGA does not provide DDC, but the DVI does ). ---------------------------------------------------------------------- marcov · 2022-08-22 11:59 I played a bit with EDID too once(*), and from what I saw most monitors simply have some defaults filled in. There are no deep details there. And what Pascal Dragon says, it can vary how you connect it. (*) Mostly to get a two monitor apps to not swap screens accidentally. ---------------------------------------------------------------------- MarkMLl · 2022-08-22 12:15 I /thought/ I'd retrieved it in the past via the BIOS, but I didn't want to commit myself lest somebody (and I'm sure it wouldn't be OP, who's a pukka gentleman) subsequently came along with "OK smartarse, tell me how to get that from Lazarus". /However/ it does occur to me that, while an accurate DPI value might be a piffling engineering detail, X/Y resolution (in pixels) and size (in either mm or "Freedom Units") are both of overwhelming interest to marketroids so are likely to be reported accurately hence DPI may be calculated. Actually retrieving those values is another matter and making sure that they're from the monitor rather than a "near-enough" driver is another matter entirely... MarkMLl ---------------------------------------------------------------------- marcov · 2022-08-22 12:23 The problem is that afaik the monitor only yields a generic value so that Windows XP and non PC hardware can deal with it without problems. Probably for creatives the real values were patched (in XP times) by the .INF only driver that usually also configured colour profiles. ---------------------------------------------------------------------- MarkMLl · 2022-08-22 13:16 I've just been looking back through data I captured using a Raspberry Pi processed using (I think) the standard edid-decode utility. I've got files for a couple of monitors/TVs, and I think it's actually the more generic TV that gives the useful info: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Extracted contents:header:          00 ff ff ff ff ff ff 00serial number:   63 18 00 00 00 00 00 00 17 18version:         01 03basic params:    80 00 00 00 0achroma info:     d7 a5 a2 59 4a 96 24 14 50 54established:   a3 08 00standard:        d1 c0 b3 00 81 00 81 80 81 40 81 c0 01 01 01 01descriptor 1:    04 74 00 30 f2 70 5a 80 b0 58 8a 00 44 17 74 00 00 1edescriptor 2:    7f 21 56 aa 51 00 1e 30 46 8f 33 00 3f 43 21 00 00 1edescriptor 3:    00 00 00 fd 00 32 4c 1e 50 10 00 0a 20 20 20 20 20 20descriptor 4:    00 00 00 fc 00 54 56 0a 20 20 20 20 20 20 20 20 20 20extensions:      01checksum:        05 Manufacturer: XXX Model 0 Serial Number 0Made week 23 of 2014EDID version: 1.3Digital displayImage size is variableGamma: 1.00Supported color formats: RGB 4:4:4, YCrCb 4:4:4First detailed timing is preferred timingEstablished timings supported:  720x400@70Hz  640x480@60Hz  800x600@56Hz  800x600@60Hz  1024x768@60HzStandard timings supported:  1920x1080@60Hz  1680x1050@60Hz  1280x800@60Hz  1280x1024@60Hz  1280x960@60Hz  1280x720@60HzDetailed mode: Clock 297.000 MHz, 1860 mm x 1047 mm               3840 4016 4104 4400 hborder 0               2160 2168 2178 2250 vborder 0               +hsync +vsync Detailed mode: Clock 85.750 MHz, 575 mm x 323 mm               1366 1436 1579 1792 hborder 0                768  771  774  798 vborder 0             +hsync +vsync Monitor ranges (GTF): 50-76Hz V, 30-80kHz H, max dotclock 160MHzMonitor name: TVHas 1 extension blocksChecksum: 0x5 (valid) CEA extension blockExtension version: 349 bytes of CEA data  Video data block    VIC  16 1920x1080@60Hz (native)    VIC   5 1920x1080i@60Hz     VIC   4 1280x720@60Hz     VIC   3 720x480@60Hz   VIC   7 1440x480i@60Hz     VIC   2 720x480@60Hz     VIC   6 1440x480i@60Hz     VIC   1 640x480@60Hz     VIC  31 1920x1080@50Hz   VIC  20 1920x1080i@50Hz     VIC  19 1280x720@50Hz     VIC  18 720x576@50Hz     VIC  22 1440x576i@50Hz     VIC  17 720x576@50Hz     VIC  21 1440x576i@50Hz     VIC  32 1920x1080@24Hz   Audio data block  Linear PCM, max channels 2    Supported sample rates (kHz): 48 44.1 32    Supported sample sizes (bits): 20 16    AC-3, max channels 6    Supported sample rates (kHz): 48 44.1 32    Maximum bit rate: 640 kHz    Dolby Digital+, max channels 8    Supported sample rates (kHz): 48 44.1 32  Speaker allocation data block    Speaker map: FL/FR  Vendor- specific data block, OUI 000c03 (HDMI)    Source physical address 4.0.0.0    Maximum TMDS clock: 300MHz    Extended HDMI video details:      HDMI VIC 0 3840x2160@30Hz      HDMI VIC 1 3840x2160@25Hz      HDMI VIC 2 3840x2160@24Hz  Extended tag: YCbCr 4:2:0 video data block    VIC  96 3840x2160@50Hz     VIC  97 3840x2160@60Hz Basic audio supportSupports YCbCr 4:4:4Supports YCbCr 4:2:24 native detailed modesDetailed mode: Clock 74.250 MHz, 708 mm x 398 mm               1280 1720 1760 1980 hborder 0                720  725  730  750 vborder 0               +hsync +vsync Detailed mode: Clock 74.250 MHz, 708 mm x 398 mm               1920 2448 2492 2640 hborder 0              540  542  547  562 vborder 0               +hsync +vsync interlaced Detailed mode: Clock 27.000 MHz, 531 mm x 398 mm              720  736  798  858 hborder 0                480  489  495  525 vborder 0               -hsync -vsync Detailed mode: Clock 27.000 MHz, 531 mm x 398 mm                720  732  796  864 hborder 0              576  581  586  625 vborder 0               -hsync -vsync Checksum: 0x77 (valid)  Note there that even though the basic EDID hasn't been filled in usefully, by the time one gets into the extension blocks and knowing the current monitor size in pixels from the LCL one has a reasonable chance of selecting the correct size from the options: Code: Text  [Select][+][-]window.onload = function(){var x1 = document.getElementById("main_content_section"); if (x1) { var x = document.getElementsByClassName("geshi");for (var i = 0; i Detailed mode: Clock 297.000 MHz, 1860 mm x 1047 mm               3840 4016 4104 4400 hborder 0               2160 2168 2178 2250 vborder 0             +hsync +vsync I'm not saying it's foolproof, and in particular it's not foolproof if the manufacturer used a generic controller or one was swapped in during a repair ** . However I think it's likely to be a good start if the manufacturer is half-way reliable. ** That's actually a cheap 40" TV from a rarely-heard-of manufacturer almost certainly bought from one of the less reputable supermarkets' cut-price bin. MarkMLl ---------------------------------------------------------------------- SymbolicFrank · 2022-08-22 13:25 And don't forget, that not all pixels are square... ---------------------------------------------------------------------- J-G · 2022-08-22 13:30 Quote from: MarkMLl on August 22, 2022, 11:10:44 am[...] You can, by and large, get the pixel count (X * Y) of the display panel. You can, by and large, get the monitor model name. I'd suggest that the best you can do is find a table which cross-references model name (subject to misspellings :-) with panel size, and /suggest/ this to the user... but ask for confirmation or override before relying on it for DPI. It seems to me that Screen.Width and Screen.Height will provide the basic X,Y resolution and for accurate sizing of images you simply need the Monitor Pixel Size which should be available from the User Manual (not that any end user ever bothers to read such matter!) or marketing material. The arithmetic to calculate the 'scale factor' is trivial. This reminds me of my days in the drawing office where every drawing was anotated with details of the scale at which the images had been drawn but there was always a large [DO NOT SCALE] sign added ---------------------------------------------------------------------- MarkMLl · 2022-08-22 13:31 Yes, which is another reason to start with the marketroid-significant X/Y pixels/mm parameters if possible. In fact, I don't see any mention of a DPI value in that EDID data: possibly because it originated from monitors which would be less likely than TVs to assume a standardised aspect ratio. MarkMLl ---------------------------------------------------------------------- J-G · 2022-08-22 13:35 Quote from: SymbolicFrank on August 22, 2022, 03:25:12 pmAnd don't forget, that not all pixels are square...That may - or may not - matter if the Pixel Pitch is the same V & H,   but I take your point. ---------------------------------------------------------------------- MarkMLl · 2022-08-22 13:38 Quote from: J-G on August 22, 2022, 03:30:31 pmIt seems to me that Screen.Width and Screen.Height will provide the basic X,Y resolution and for accurate sizing of images you simply need the Monitor Pixel Size which should be available from the User Manual (not that any end user ever bothers to read such matter!) or marketing material. I can't remember whether the values have to be got from the Screen or Monitor specification buried in the LCL's Application object: one of those is the current display while the other refers to the entire desktop (i.e. potentially multiple displays). QuoteThis reminds me of my days in the drawing office where every drawing was anotated with details of the scale at which the images had been drawn but there was always a large [DO NOT SCALE] sign added Which is fine provided that the person interpreting the drawing understands the annotations, and the metadata that indicates that something is an annotation applying to the drawing rather than to the end product. I've got a little Chinese-made PSU on my desk where the manufacturer name silkscreened on the front is proudly announced to be PRODUCT SCHEMATIC. MarkMLl ---------------------------------------------------------------------- J-G · 2022-08-22 14:17 Quote from: MarkMLl on August 22, 2022, 03:38:29 pm[...] I can't remember whether the values have to be got from the Screen or Monitor specification buried in the LCL's Application object: one of those is the current display while the other refers to the entire desktop (i.e. potentially multiple displays). [...]In a different project I did need to know the total space available and I had to look back at that project to remind me how I did it. In fact Monitor & Screen (Height & Width) both return the same values. With multiple screens (which I have) you need to interogate Screen.DesktopWidth. With only two screens of course the DesktopHeight will be the same as Screen.Height, and how one would indicate a multi- row, multi-wide set I have no idea!