HMI bitmap import shows a red X: fix the image file

What does a red X after a bitmap import mean?

The red X is the editor's empty-picture mark: the import command ran, found nothing it could decode in the file, and left a crossed box on the screen object instead of your image. The mark tells you one thing: the picture never arrived in the project. The screen object, its size, its position and the screen logic are all untouched, so nothing on the screen needs repair. Work on the file, and the red X goes away on the next import.

Match your case against these symptoms:

• The red X appears for every image you import, including a small screenshot: the fault sits with the editor or its import function, so go straight to the controlled test below.
• The red X appears for one photo you saved as a bitmap: that file is a bitmap variant the importer refuses, or it is not really a bitmap, so run the viewer test in the next section.
• The red X appears for a picture taken from a web page: you saved the page's wrapper or a link, so save the image file itself to disk and test that file.
• Paint cannot open the file either: the file is corrupt or misnamed, so rebuild the image from the original photo, camera card or drawing file instead of repairing the copy.
• The picture imports and shows in the editor but looks wrong on the running panel: the import succeeded and the fault sits in the display path, which the last section covers.

Why does a photo saved as a bitmap still fail?

The name BMP covers a family of encodings, and an HMI importer reads the plain one: uncompressed color at 24 bits per pixel, which is 8 bits each for red, green and blue. The BMP format stores two-dimensional images at many color depths, from 1-bit line art to 32-bit with an alpha channel, and it supports optional data compression for the low-color depths. Import functions in HMI software were written for the plain subset: uncompressed 24-bit color. A photo app that saves as bitmap often writes a compressed variant or 32-bit data, and a picture on a web page stays a rendered image until you save the actual file to disk. The importer meets an encoding it cannot use and draws the red X.

The working rule is the one HMI support desks have handed out for years: if the desktop viewer will not open it, the editor will not import it either. Paint is the convenient viewer because it is already installed on the Windows PC your editor runs on.

How do I test the image file before touching the project?

Open the exact file you imported, by its full path and folder, in Paint: if Paint displays the picture, the file is readable and the failure is an encoding variant, and if Paint cannot open it, the file itself is broken or misnamed. Run the test in this order:

1. Find the exact copy you imported. Where several copies exist, match the name and the folder first, so you test the file the editor actually read.
2. Open Paint and open the file from it. If the picture shows, note its pixel size in the viewer, because the size calculation below uses it.
3. If Paint refuses the file, stop converting copies and go back to the source: the camera card, the phone or the original drawing. Save a fresh image from there and test that one.
4. Treat a file that opens in Paint as readable and still keep the resave in the plan, because the encoding stays the likely fault after the viewer test.

Worked example: how big is a 640 x 480 24-bit BMP?

A 640 x 480 picture in plain 24-bit color holds 640 x 480 = 307,200 pixels, and each pixel stores 3 bytes, one each for red, green and blue, so the pixel data is 307,200 x 3 = 921,600 bytes, exactly 900 KB. The rest of the arithmetic you will meet on real files:

• Rows in a BMP are padded up to a multiple of 4 bytes. Each row here is 640 x 3 = 1,920 bytes, which divides by 4 exactly, so no padding is added. A 641-pixel-wide picture needs 1,923 bytes of data per row, rounded up to 1,924.
• Two file headers add about 54 bytes in front of the pixel data, so the finished file is 921,654 bytes.
• The same picture as a JPEG runs near a tenth of the size, because photographic JPEG compression works around 10:1, roughly 90 KB here. That is why editors that accept JPEG save panel memory on photographs, and why a folder of full-size BMP screenshots fills it fast.
• A 4,000 x 3,000 phone photo resaved at 24 bits becomes 4,000 x 3,000 x 3 = 36,000,000 bytes, about 36 MB. Resize the picture to the size it will appear at before you convert it.

What are the steps that fix it?

Make a fresh copy of the image in Paint and save it as a plain 24-bit bitmap, then import that copy, because this swaps whatever encoding the editor refused for the encoding HMI import functions are built to read. Work in this order:

1. Save the project, then work on a copy and keep a master elsewhere; the routine in keeping a master copy of an HMI project covers the backup side.
2. In Paint, open the original image, use Save as, pick the bitmap type, and choose the 24-bit option where the viewer offers a choice of color depth. Give the copy a new name so the original stays untouched.
3. Open the new file once, check the picture shows, then import it with the same import command that produced the red X and place it on a test screen.
4. Send the project to the panel and check the picture on the HMI itself, not only in the editor. Do the edit while the machine is idle, so a half-finished screen never sits in front of an operator.
5. When the copy imports and displays, convert the rest of the failing pictures the same way, one at a time, until the screen is complete.

Recommendation: when a static bitmap import shows a red X, open the exact file in Paint first. If Paint opens it, resave a copy as a plain 24-bit BMP and import the copy. If Paint cannot open it, rebuild the file from the original source. Move on to project, transfer or editor checks only when a known-good 24-bit copy still fails.

What if the resaved bitmap still shows a red X?

Import one small picture that Paint has already displayed into a fresh test screen, because one known-good file, one screen and one import attempt separate a file problem from a project or editor problem. Two results, two paths:

• The known-good copy imports. The remaining fault is in the original file's conversion, so redo the resave from the true source image and check the saved copy's color depth in its properties before importing again.
• Even the known-good copy fails. Stop changing files: the fault sits in the project copy or the editor installation. Try a second test image and a different test screen, and open the project copy on another PC. If the failure follows the project, rebuild the screen. If it follows the PC, repair or reinstall the editor from your HMI software's maker and send them the project copy and the test image. The failure patterns repeat across HMI brands, and a walkthrough of troubleshooting BMP bitmap imports into HMI panel software runs through the same file-side checks.

How do I keep imported images small enough for the panel?

Size the picture to the object it will fill before converting, because a 4,000 x 3,000 phone photo becomes a 36 MB 24-bit BMP, while a 640 x 480 copy of the same picture stays under 1 MB. Three habits cover most projects:

• Photographs: convert to JPEG where your editor accepts it, around 10:1 smaller than the same picture as a BMP, and keep the 24-bit BMP copy beside it as the fallback.
• Logos, screenshots and text graphics: stay with 24-bit BMP, because JPEG compression smears hard edges and small text.
• Flat-color graphics: a 256-color BMP stores 1 byte per pixel, so the 640 x 480 example drops from 921,600 bytes to 307,200 bytes with no visible change.

When a project keeps growing and panel memory runs short, the trimming steps are in fitting product images on an HMI when bitmap memory runs out.

A separate notice board in the same plant, one that only plays picture slides from a memory card offline, is a job for our panel-mount signage displays, with no subscription.

When is it the screen and not the file?

If the imported picture sits correctly in the editor but the running panel shows wrong colors, a tint or a black box, the import succeeded and the fault has moved to the display path, the project's image settings or the panel itself. Keep the two failures apart: a red X in the editor is a file the software could not decode, while a picture that decodes but displays wrong is a panel-side fault. For a panel that shows a white background as a red tint, the diagnosis moves to an HMI screen that shows a red tint instead of white. A picture present in the editor but missing on the panel after a send is a transfer problem: send the project again and check the panel's storage before you suspect the image.

Questions