Why we checked pixels before publishing the pictures
A picture can pass one check while another question remains unanswered. For ThisPlaceAhead, we separately checked the decoded image data, the release package and the files delivered by the public website.
The question behind the work
The problem
ThisPlaceAhead was moving a set of prepared Middelburg scenes from its image workflow to the public website. The release used WebP versions of the source images. We needed evidence that those versions preserved the image data we had reviewed, and that the website actually delivered the intended release. Looking at a few pictures could not answer both questions for the complete set.
01
What we tried
- Compared each of 30 source-image and WebP pairs independently. The review decoded both files into full RGBA image buffers and compared every value, while also checking their dimensions. RGBA means the red, green, blue and transparency values of each pixel.
- Checked the exact release package separately, including the expected state of the public paths before replacement and the prepared rollback package. Image comparison was one release requirement, not a substitute for checking the rest of the site.
- After publication, checked all 41 release files at their public URLs. We compared each delivered file with the expected release file and checked its HTTP response. This included the 30 image files as well as the pages and supporting files.
02
What happened
- All 30 named pairs passed the independent comparison: their decoded RGBA buffers were exactly equal at the original dimensions of 3344 by 1882 pixels. This was a result for these pairs using the recorded decoder, not a claim about every possible image conversion.
- The package check established the exact candidate for publication and a bounded rollback. It answered which release was being handled, while the pixel comparisons answered what had been preserved inside the image files.
- All 41 public release files then returned successful HTTP responses and matched their expected file hashes. The image files were part of that complete delivery check, rather than being assumed correct because the page loaded.
- Some weather slots shared the same image content. We therefore report 30 checked pairs and 30 delivered image files, not 30 visually unique scenes. We did not measure a speed improvement, a reduction in transfer cost or an improvement in perceived image quality.
- A separate homepage photo release later on 7 September exposed another layer. Its first ZIP contained the correct seven files, but the archive stored owner-only permissions (0600). After extraction, the English and Dutch homepages returned HTTP 403. We rebuilt the package with explicit file permissions of 0644. The seven member files remained byte-for-byte identical between the two archives; the archive metadata changed. After the replacement was extracted, both homepages returned HTTP 200. Public checks matched the expected hashes for all seven changed files and thirteen preserved files. These were separate checks from the earlier 30 image pairs and 41 release files.
03
What we learned
Choose the comparison that answers the question. A file hash identifies the bytes of an artifact. For this conversion, we also needed to compare the decoded image data with the source. A matching release-file hash alone would not demonstrate that relationship.
Keep transformation checks and delivery checks separate. A correct local derivative does not establish which file a public server is delivering; a correctly delivered file does not establish that its transformation preserved the intended data.
Define the denominator before reporting a pass rate. Named variants, files, unique images and public routes are different counts. In this case, thirty successful pair comparisons and forty-one successful delivery checks described different parts of the work.
An exact result can still have a narrow scope. These checks established decoded pixel equality and delivery of the selected files. They did not assess source rights, real-world scene accuracy, browser rendering performance or what viewers would perceive.
The follow-up lesson is to check packaging metadata as well as content. Correct file bytes did not make these pages publicly readable. For this recovery, permission inspection explained the failure, and HTTP responses plus file hashes established the restored delivery. Future packages need explicit file modes and a public availability check after extraction.
04 · Outcome
The decision
ADOPT. Use separate evidence for the source-to-derivative relationship, the selected release package and public delivery. Keep the verified ThisPlaceAhead release, and retain the original comparison boundary when describing what passed.
Where the evidence leads
What this means next
Apply the same checks when a later release changes an image or its delivery format. Recheck the affected pairs and the published files; do not carry an earlier pass forward to new bytes without testing them. Any later performance or visual-quality claim needs its own measurement.
View the Middelburg scenes →