Dealing with Business Images with Variants

READ ALSO: Images in Web Applications

Speaking of images in web applications, an additional point to consider—beyond choosing the most effective storage medium—is how to deal with multiple variants of the same image that may need to be stored and served.

If, in general terms, storage can be one of a few options—database, file system, or blob—when multiple variants of the same image are involved, storing the bytes in blob storage becomes inevitable and, in practice, the only savvy option to consider.

Why Multiple Variants?

Modern web applications make their content available across a variety of devices and business scenarios. This flexibility comes with the additional cost of serving images according to their context. Typical variants of a business image may involve:

• Different size and resolution
• Different color scheme
• Different content and semantics

Let’s delve deeper.

Different Size and Resolution

This is by far the most common reason for having multiple versions of the same image. The same photo may be displayed as a thumbnail in a list, as a medium-sized image on a detail page, and as a large, high-resolution image in a gallery or full-screen viewer. Not to mention the requesting device. Even though modern networks have reduced the impact of image size, mobile devices may still benefit from receiving images tailored to their actual display requirements. The reason is not only the smaller screen, but also the fact that downloading unnecessary pixels wastes bandwidth and battery.

Serving the original image and relying on the browser to scale it down is technically possible, but it is often a poor use of resources. If a 4000×3000 photo is displayed as a 200×150 thumbnail, the browser still has to download the original payload just to discard most of the pixels.

The natural solution is therefore to have several physical representations of the same logical image.

Different Color Scheme

Size is not the only dimension along which an image can vary. Sometimes an image may need different color characteristics depending on where and how it is presented. A classic example is dark mode. An image containing text, logos, diagrams, or other UI-oriented content may require a light-background and a dark-background version rather than merely being resized. Another example is an image prepared for printing versus one intended for a screen. Different color profiles, compression settings, and output characteristics may be appropriate even when the visible subject is identical.

A canonical example is just a company logo: dark, light, print, monochrome, not to mention the file format (PNG, JPG, SVG), geometric variants (horizontal, square, and so on), and transformations such as cropping, background removal, sharpening, compression, and watermarking. It is crucial to recognize that these are not simply different resolutions. They are different renderings of the same underlying business asset.

Different Content and Semantics

Another interesting case is when variants are not merely technical transformations but represent different content or semantics.

Consider a product photograph. The original image might show the entire product, while the image used in a search result might be deliberately cropped to emphasize the product itself. A marketplace may use another crop for a promotional banner and yet another image for a product-detail gallery. The same applies to photographs of people. An image may exist as a headshot, a full-length portrait, or a mid-length portrait. In some domains, such as sports media, even the left/right alignment of the subject can be an important parameter. More, the same principle applies to editorial content too. An article may have a hero image, a thumbnail, a social-sharing image, and an image optimized for a particular placement. They may originate from the same photograph, but they serve different purposes and therefore may have different poses.

At this point, it is no longer simply a matter of dealing with multiple image resolutions. A 1200×600 image intended for social sharing is not necessarily equivalent to another 1200×600 image intended as a page hero. The dimensions are identical, but the semantic purpose is different. One may be composed specifically around the constraints of a social-card layout; the other may be optimized for the article itself.

In short, an image variant is not necessarily a smaller or larger copy of the same image. It is a representation of that image for a particular context. In a web application, therefore, the same logical image is represented by an image identity and a set of related physical representations. This is where blob storage becomes particularly attractive.

One Logical Image, Many Physical Objects

With multiple files per image, the database risks becoming a warehouse for binary content and the web application a file server in addition to its normal workload. Neither is desirable.

More importantly, the physical representation of an image can evolve without changing its logical identity. New representations may come from new file formats—first JPEG, then WebP, and later perhaps AVIF. A new device class may require a different resolution, while a new business requirement may introduce a different crop or pose. One logical image, but potentially many physical representations, requires application designers to manage storage and retrieval in a more sophisticated way than simply choosing a storage medium. The basic rules are straightforward:

1. The image is uniquely identified by an ID.
2. The bytes of all representations go to blob storage.
3. Metadata describing the representations goes to a database table.
4. The retrieval logic starts with the image ID and uses the associated metadata to identify the appropriate representation.

The image ID is application-specific. For a product, an excellent candidate is any code that uniquely identifies the product. The blob will preferably have a dedicated container and, within that, one “folder” per image ID. As mentioned earlier, in blob storage a folder is simply a token in the full blob name, not a real sub-container, even though tools such as Azure Storage Explorer represent blobs using files-and-folders terminology similar to Windows Explorer.

Each image ID references (like a virtual folder) the various representations available for that image. In blob, some application-specific naming convention is therefore required. For example:

1234/default.png

1234/white.png

1234/full.webp

1234/mid.webp

This says that product 1234 has four available representations. Conventionally, default indicates the default full image, white represents the light-background version, and full and mid represent different compositions or sizes. This is just an example, although a realistic one.

Image Metadata

Who decides that the images related to product 1234 are PNG for default and white, but WebP for full and mid? That information belongs in the metadata stored in the database, associated with the product ID.

A further question is the schema of that table. Should there be one column for each supported scenario—default, white, full, and so on? Or is a one-to-many relationship better, with multiple records, each describing a single representation through a set of attributes such as is-default and is-white? Both options are viable. The main discriminant is the number of resulting columns if a single record is used. Furthermore, a single-record design requires a schema change whenever a new representation is added or an existing one is removed. In general, the one-to-many pattern is more flexible. At the same time, it can be overkill when an image ID has only one or two representations and no foreseeable change is expected.

The final point about image management in web applications is building the URL for a specific image and format, and the help we can get from HTML and browsers.