A 640 x 480 image on an HMI web page has one of two limits: the pixels stored in the file, or the markup that sizes the image. Open the file directly and read its intrinsic size. Below the 1024 × 768 area you want, replace the file with a larger export; at or above it, set width and height in the page and keep the 4:3 ratio.
A panel web page serves its status image at 640 x 480 pixels and you want it at 1024 × 768. Two different values can set that size: the pixels stored inside the image file, or the markup that tells the browser how big to draw it. HTML can draw a small file in a large area, but every added pixel is interpolation, so the picture gets bigger and softer and no detail comes back. Find out which value is the limit before you edit anything: open the image file directly and read its size. A file that really is 640 x 480 pixels needs a replacement at higher resolution. A larger file held down by the page needs a markup or CSS change, with the 4:3 ratio kept. This article gives the checks, both fixes and the arithmetic that tells them apart.
Read the file's own pixel count first
Open the image address on its own, in a browser tab, with the page out of the way. On the panel in this case the address is the panel's address followed by the image path your page actually uses, with the image's own file name at the end. What the browser shows then is the file drawn at its intrinsic size, the size stored in the file, with no markup involved. The properties dialog of the same file saved to disk shows the same numbers. Some files also carry an intrinsic size and pixel density in their EXIF data, so read the pixel dimensions from the file itself before you blame the page.
Record three numbers and keep them separate:
- the file's intrinsic size in pixels, read as above
- the size the page currently draws the image at, read from the page source or the browser's inspector
- the display area you want, here 1024 × 768 pixels
Pixels in the file and pixels on the panel's screen are two different counts, and the screen has the final word on sharpness. The screen side of that relationship is its own subject: why two HMI panel sizes share one layout in pixels covers it.
Symptoms and what each points to
- The image sits small in a mostly empty page. The browser is drawing the file at its intrinsic size. The file is the limit.
- The image fills the area but looks soft. The markup enlarged a smaller file, and the softness is interpolated pixels. The file is the limit.
- The image looks stretched or squashed. The width and height in the markup have a different ratio than the file's own ratio. The markup is the problem.
- Zoom makes everything bigger but no sharper. Zoom changes how the whole page is presented, text and controls included. The file's pixels are unchanged, and controls can end up off-screen, so zoom is a quick check, never the fix you leave in place.
- Your edit works on the desk browser, then the panel page reverts. The panel serves pages generated from its project, and the next project download rebuilds them. Move the change into the project source.
Fix the page when the file has the pixels
If the file reads 1024 × 768 pixels or larger and the page keeps it small, the markup is the limit. Standard HTML carries the size on the image element itself:
<img src="ip/image.jpg" width="1024" height="768" alt="Line 3 mixer status">
ip/image.jpg stands for the image path your own page references; use that path and your own alt text. width and height are standard HTML attributes, in pixels.
If the page sizes images with CSS, change that rule and remove conflicting width and height attributes, so one place decides the size. Two places fight.
Keep the file's own ratio. 1024 × 768 is 4:3, so a 4:3 file fills it with no distortion. A file with a different ratio, say 1600 x 900 pixels (16:9), distorts if you force both numbers: set the width to 1024 and let the height follow to 576. Where the page is styled with CSS, the aspect-ratio property pins the ratio for you; CSS container queries for aspect ratio control walks through the method on control-system pages.
Example: a 640 x 480 file drawn in a 1024 × 768 area
Inputs. The file's intrinsic size, 640 x 480 pixels, read by opening the image file on its own; this is the case this article answers. The target display area, 1024 × 768 pixels, the size requested for the page.
Rule. Two checks decide. The ratio check: if the file's ratio equals the area's ratio, the drawing keeps its proportions. The pixel-count check: if the file holds fewer pixels than the area, enlargement adds pixels the file never had.
Arithmetic.
- Ratio: 640 divided by 480 is 1.33, and 1024 divided by 768 is also 1.33. Both are 4:3, so drawing the file at 1024 × 768 distorts nothing.
- Enlargement: 1024 divided by 640 is 1.6. Each source pixel is spread across 1.6 screen pixels.
- Pixel count: 640 x 480 = 307,200 pixels in the file. 1024 × 768 = 786,432 pixels in the drawing area. The difference, 786,432 - 307,200 = 479,232 pixels, is filled by interpolation.
Result. The image comes out bigger and correctly proportioned, and soft. Small text, gauge markings and fine traces in the image blur first at 1.6x.
Decision. Compare the file's pixel count with the area's. Below 786,432 pixels, a scale factor above 1: replace the file, because enlargement adds size and no detail. At or above 786,432 pixels, a scale factor of 1 or less: the page is the limit, so set the markup or the CSS rule and keep the file.
Replace the file when the file is the limit
Regenerate the image from its source at the size you need, 1024 × 768 pixels or larger. An application screen or diagram gets exported again at the larger size from the tool that produced it. A camera still gets taken or exported larger. A crop out of the 640 x 480 original still carries 640 x 480 worth of detail, at most.
Keep the same file name and path the page already references, and the replacement lands with no markup edit. Keep a copy of the old file and a note of which page references it, so you can go back.
After the swap, open the file on its own and read 1024 × 768 pixels from it. Then load the page through the same address and browser the operators use. The panel's screen sets the final size everything is drawn at, so the pass check happens there.
Make the change survive the next project download
Panels that serve web pages usually generate those pages from the project, and a project download rebuilds them. An edit made on a served file lasts until that download, then disappears. Put the change where the page comes from: the image asset and the page layout in the project source. Run a normal project update, let the page regenerate, and load it again; if the fix survives that, it stays. The safe order for handling the project files themselves, backup before edit and a restore tested before you need it, is in back up and restore an HMI panel project the safe way.
Checks before you call it done
- The file, opened on its own, reads the size you intended: 1024 × 768 pixels after a replacement, the file's original size after a markup fix.
- The page, loaded through the operator's address and browser, draws the whole image with correct proportions: nothing clipped, nothing squashed, no horizontal scrolling.
- Everything else on the page still fits. A larger image can push buttons and values off the bottom edge.
- One project download and page regeneration later, the page still draws the image at the size you set.
The decision for each case
Recommendation: open the image file directly before you touch any markup. If it reads 640 x 480 pixels, replace it: regenerate from the source at 1024 × 768 pixels or larger, keep the file name and path, and let the page draw it. If it reads 1024 × 768 pixels or more, change the page: set width and height to 1024 and 768, or fix the CSS rule that sizes the image, keep the 4:3 ratio, and make the change in the project source so the next download keeps it. Either way, the pass check is the operator's panel, where the screen's own resolution has the final say.
So: file smaller than the display area, replace the file. File big enough, fix the markup. Page generated by the project, make either fix in the project, once, where a download cannot overwrite it.
Questions
Why does the image look sharp on my desk monitor but soft on the panel screen?
The two screens resolve different pixel counts. A desk monitor at 1920 x 1080 draws a 1024 × 768 area with room to spare, while a panel screen of 1024 × 768 pixels puts exactly one screen pixel on each image pixel, so every interpolated pixel in the enlargement shows. Judge sharpness on the screen the operators use, at their viewing distance.
What should the replacement image file look like?
Same file name, same path and same file type the page already references, so the swap needs no markup edit. Use PNG for diagrams, text and line drawings, where sharp edges matter, and JPEG for camera stills and photos. Export at 1024 × 768 pixels or larger and read the size back from the saved file before you rely on it.
Does setting width and height change the image file?
No. The attributes and any CSS rule change how the browser draws the file; the file keeps the pixels it was saved with. That makes a markup fix reversible: remove the attributes and the image draws at its intrinsic size again. A replacement file is the step that changes what detail exists.
Can the image be shown larger than the panel screen itself?
The browser can only draw inside the screen it runs on. An image set wider than the panel's resolution brings horizontal scrolling or a cropped edge, and operators lose part of the picture. Size the image to the page area the panel actually shows; on a 1024 × 768 screen that means 1024 × 768 pixels for a full-screen image, less once headers and buttons take their share.
Planning information, not legal or engineering advice. Rules differ by place: check codes and permits with your local authority and your licensed trades.