Repair the sideways product photo before replacing the catalogue

A product photo looks upright on the supplier's phone and sideways in the website's small card. The larger view may look correct again. To the person maintaining the catalogue, the inconsistency can make the whole publishing system seem unreliable.

It is worth tracing how the image changes before deciding to replace the platform. A repair may belong in the step that prepares smaller files, while the catalogue's product records, language pages and enquiry links remain useful. The following fictional example shows what evidence would support that narrower choice.

Compare the actual files

An Argentine workshop publishes photographs of its display stands. One phone photograph is correct when opened in an application that reads its orientation information. The small derivative generated for the product grid lies on its side. Staff have tried uploading the same original again, with the same result.

The investigation compares the original, the generated small image and the exact file requested by the grid. That rules out two other plausible explanations: the page linking to an old upload and a layout rule rotating the image. The faulty derivative itself is sideways when viewed outside the page.

The source file contains both pixels and an EXIF orientation instruction. The processing step resizes the pixel array and strips metadata without first applying that instruction to the pixels. The derivative therefore loses the information that told an aware viewer how to orient the source.

This is a specific processing fault, not evidence that all phone photographs or all metadata removal behave this way. Other images can already have upright pixels or no applicable orientation instruction. The repair needs to respect those differences.

Correct the order of operations

For this pipeline, apply the source's orientation before creating the web derivatives. Then remove or reset the orientation instruction as appropriate to the chosen processing method so a later viewer does not apply the same transformation again. The resulting derivative should carry the intended visual orientation in its pixels.

Pillow's documentation for EXIF transposition describes one implementation that applies the orientation and removes the orientation data. That illustrates the operation; the project should use the supported equivalent in its own processing system.

Avoid adding a blanket quarter-turn to the product grid. It may make the failing photograph appear upright while rotating every image that was already correct. A page-level visual patch also leaves the underlying file wrong when somebody uses it in another page or download.

Retain the approved original separately. Correct processing does not establish permission to publish the photograph, and a useful original may still contain metadata that should not appear in a public derivative. Decide the public metadata policy as part of image preparation rather than retaining everything simply to preserve orientation.

Check more than the first corrected thumbnail

The fictional acceptance set includes the original failing photograph, an upright image with ordinary orientation, a source without an orientation tag and a second source that requires a different supported orientation. Compare visible landmarks such as the stand's top, base and printed label; dimensions alone cannot prove that an image is not mirrored or upside down.

Generate each size the site actually serves and confirm the page requests those corrected derivatives. Check the product grid, detail view and relevant responsive sizes. If a cache can continue serving the old asset, use the site's documented replacement or versioning process and verify which bytes are delivered in the preview.

Reprocessing an already normalised derivative should not rotate it again. An unchanged control product should retain its appearance, code, caption and enquiry destination. The Spanish and English catalogue pages should continue to identify the same approved product rather than acquiring separate manual image fixes.

In the example, these checks support a limited result: the identified pipeline now prepares the sample images correctly. They do not establish that every existing derivative has been regenerated. Inventory the affected files and plan any wider repair separately, preserving associations with the correct product variants.

Decide whether a larger replacement is justified

The narrow repair is attractive when the business can maintain the processing step, obtain the necessary originals and preserve the catalogue's working relationships. It addresses the demonstrated cause with less migration work than rebuilding the whole site.

A replacement may still deserve consideration if the existing system cannot be maintained, does not expose a supported way to correct image processing, or has other independently established limitations. Compare those constraints with the effort to move product identifiers, approved documents, language relationships and existing URLs. The sideways image alone does not answer that wider question.

Bring the original file and the faulty derivative to a technical review through an appropriate channel, together with the public page where the difference appears. The website care service can begin with that investigation. A clear diagnosis gives the business a sounder basis for choosing a repair, a component change or a broader rebuild.