Fit product images on an HMI when bitmap memory runs out

Why bitmaps fill the memory

A bitmap stores every pixel. The storage cost is width × height × bytes per pixel, and 24-bit color is 3 bytes per pixel. The file header adds a few hundred bytes and each row is padded to a 4-byte multiple, both negligible at the widths used here.

The same picture can carry very different pixel counts. A camera photo at 4000 × 3000 holds 36,000,000 bytes of pixel data. Resized to 640 × 480, it holds 921,600 bytes. On a picture window that shows 640 × 480 pixels the two look identical, and the first stores 39 times the pixel data. Scaling the picture down inside the editor changes only what is displayed, so resize outside the project.

Color depth moves the same number: 16-bit color is 2 bytes per pixel and 8-bit is 1.

Weight also costs runtime speed. When heavy bitmaps show up as slow data updates on the same screen, the fixes sit in Fix an HMI bitmap that slows PLC data updates.

Three fixes that look right and are not

What you need

• The JPEG master folder, kept untouched: it is the small, editable source for every later batch.
• A batch image tool that resizes and converts a whole folder in one pass.
• The HMI project software, open on the screen that carries the picture window.
• The panel datasheet, for the native resolution and the project memory figure.
• The panel manual, for the removable-card path in the later section.
• The memory card the manual lists, if you expect to need it.

Resize, convert, import

1. Read the picture window's size in pixels from the editor. That pixel size, not the panel's full resolution, is the resize target; a product photo rarely needs the whole screen.
2. Crop dead background out of the masters first. Every cropped pixel is storage you never import.
3. Batch-resize the folder to the target size in one pass. Keep the aspect ratio; crop to fit instead of stretching.
4. Batch-convert the resized set to the format the import accepts, BMP when that is the only choice, in the same run.
5. Leave photo color depth at 24-bit and drop to 8-bit only for logos and flat-color graphics.
6. Import each resized picture once into the project image library and place that entry on every screen where the picture appears.
7. Replace a screen-per-product design with one screen that switches library pictures from a register value. Check the object list in your installed software version for the image-selection object it offers and how it maps a register value to a picture; names vary by version.
8. Compile and read the memory usage figure the software reports. That is the number the resize had to beat, and how a project stands against panel and PLC memory limits is walked through in Sizing an HMI project against panel and PLC memory limits.

Recommendation: Resize every photo to the pixel size of its picture window before anything touches the project, convert to the accepted format in the same batch run, and import one library entry per picture. Keep photo depth at 24-bit and reserve 8-bit for logos, then use the manual's card path only if the recompiled project still overflows.

Example: ten product photos into a 6 MB picture budget

Say a workstation HMI shows one product photo at a time in a picture window of 640 × 480 pixels, the camera delivers 4000 × 3000, and the compile leaves a 6 MB picture budget.

• As full-size bitmaps: 4000 × 3000 × 3 bytes = 36,000,000 bytes, about 36 MB each. Ten photos: 360 MB, 60 times the budget.
• The JPEG folder itself takes about a tenth of that, but a BMP-only import stores the decoded pixels, so the folder size is not what the project holds.
• Resized to the window, 640 × 480: 640 × 480 × 3 = 921,600 bytes each. Ten photos: 9,216,000 bytes, about 9.2 MB, still 3.2 MB over the budget.
• Halved both ways, 320 × 240: 320 × 240 × 3 = 230,400 bytes each. Ten photos: 2,304,000 bytes, about 2.3 MB. It fits with 3.7 MB of budget left for the next products.

Decision: at a 6 MB budget, 320 × 240 is the setting that fits with room to add products. At a 9.2 MB or larger budget, 640 × 480 fits and keeps twice the linear detail, four times the pixels. At both widths the row padding is zero, so these figures are exact apart from the headers.

When resizing is not enough

Work down the list in order.

1. Project settings. At least one HMI family documents a panel-manager setting named Bitmap Option (less Memory) that reduces project size when pictures are stored below 16-bit color. If your software offers that kind of setting, switch it on and recompile first.
2. The manual's card path. HMI manuals document loading a project whose bitmaps live on removable storage, usually a memory card in a designated slot. Your own manual revision names the card type, the format and the slot; those requirements change between revisions, so read the revision you run.
3. Bench checks before the line runs: the card matches the type and format the manual lists, its capacity exceeds the compiled project size with room to spare, the project loads and runs with the card fitted, and a power cycle with the card in place brings the pictures back without a reload.
4. Treat the card as a production component. A pulled card drops pictures mid-shift, so put the slot behind a locked cover or a panel that takes a tool to open.

If the set outgrows the panel anyway, split the job. The HMI keeps the machine data, and a small signage screen beside the station carries the photo library as a repeating slideshow; our panel-mount displays play an image folder from microSD or USB with no subscription, and the range sits at panel-mount displays.

Check it before the shift

• Compile once more; the memory figure sits below the panel limit the datasheet states.
• Transfer the project and step the register through every product code. Each code shows its picture and none shows blank.
• Cycle panel power once, with the card fitted if you use one, and confirm the pictures return without a reload.
• Read the smallest detail the operator needs, a label or a connector orientation, from the working distance at the station. If the resize removed it, enlarge that one picture, reconvert and recompile; moving one photo from 320 × 240 to 640 × 480 stores 691,200 more bytes.

Questions