PosterProof — Evidence-First Event Poster Audit
Inspiration
Imagine a campus society or event organiser approves a poster and displays it publicly. Someone later replaces its QR code while leaving the rest of the poster looking almost identical. A person scanning the altered code could be directed to an unintended or potentially unsafe destination.
A similar problem occurs when important information, such as an event date, time, or location, is changed after approval without the organiser noticing.
This inspired PosterProof, a computer-vision application designed to help event organisers compare a photograph of a displayed poster against its approved master artwork. The goal is to make potential discrepancies easier to identify and review before a poster is distributed or deployed publicly.
Rather than trying to solve every aspect of fake-poster detection, I wanted to build a focused prototype that addresses specific, understandable risks and communicates the limitations of its findings.
What It Does
PosterProof is a local web application that compares two images: an approved master poster and a photograph of a potentially altered poster.
It focuses on three main tasks:
- QR payload verification: PosterProof decodes the QR code in a configured region of interest and compares its payload against the reference. If the payload differs, the application reports a mismatch. It does not search the entire poster for another QR code to substitute for the expected one.
- Monitored visual comparison: The application examines configured regions, such as an event date or time, using blurred grayscale image-difference metrics. Potential changes are flagged for human review rather than automatically classified as confirmed tampering.
- Perspective alignment and conservative refusal: PosterProof uses visual feature matching and perspective correction to align a photographed poster with its master. When the available evidence is insufficient or the alignment is unreliable, it refuses the comparison instead of presenting an uncertain result as trustworthy.
The project distinguishes between a QR payload mismatch, a visual change candidate, and a verification refusal. These outcomes communicate different findings and prevent uncertainty from being hidden behind a single pass-or-fail result.
How We Built It
Brainstorming and Design Process
The original idea was a broad fake-poster detector. During brainstorming, I narrowed the scope to a workflow that could be implemented and demonstrated within a hackathon: compare a photograph with a reference, inspect the expected QR code, and examine selected visual regions for possible changes.
The key design scenario became the same QR code with a changed date. A poster's QR code might remain unchanged even when its visible event details have been modified, so checking the QR payload alone would not be sufficient.
This led to two separate forms of analysis: QR payload comparison and monitored visual-difference analysis. It also motivated a conservative refusal state for cases where the application cannot establish a reliable alignment.
Technology Stack
PosterProof is built using:
- Python: Application logic, request handling, and comparison workflow.
- OpenCV: ORB feature detection, descriptor matching, perspective alignment through homography estimation with RANSAC, QR-code decoding, and image processing.
- NumPy: Image-array operations, matrix calculations, and difference metrics.
- Python's standard-library HTTP server: Serves the local web application without requiring a separate web framework.
- Pillow and
qrcode: Generate synthetic poster images and QR codes for the demonstration scenarios. - pytest: Runs automated tests of the core application functionality.
The user interface provides controls for selecting the master poster and poster photograph, along with built-in demonstration scenarios. The application is designed to run locally without a mandatory external server or generative AI service.
Resources and Testing
The project uses open-source libraries whose dependencies, and licenses are documented in docs/CREDITS.md. The application code is released under the MIT License, while the third-party libraries retain their respective licenses.
Google Antigravity assisted with code drafting, test scaffolding, and technical documentation. The running prototype does not call a generative AI service or bundle a pretrained AI model. Its core image-analysis pipeline uses traditional computer-vision and image-processing techniques.
For testing, I created synthetic poster fixtures so that specific scenarios could be reproduced consistently. The application includes four demonstration cases:
- Changed QR code: The QR payload in the configured region differs from the reference, so PosterProof reports a mismatch.
- Changed date: The QR payload matches, but the monitored date region is flagged as a change candidate for human review.
- Unchanged sample: The images align, the QR payload matches, and the monitored region remains below the configured pixel-difference threshold.
- Insufficient visual evidence: The application refuses to establish a reliable comparison.
The repository includes a pytest suite for checking core pipeline behaviour. These tests and synthetic fixtures help verify intended behaviour under the tested conditions, but they are not evidence of real-world security effectiveness.
Challenges I Ran Into
One of the main challenges was aligning a photograph with its approved reference. A poster photographed at an angle can appear substantially different from the original because of perspective distortion. PosterProof uses ORB feature detection and matching, followed by homography estimation with RANSAC, to rectify the photograph when enough reliable matching evidence is available.
Another challenge was separating changes to machine-readable content from changes to visible information. A matching QR payload does not establish that the rest of the poster is unchanged. I therefore designed the QR audit and monitored visual comparison as separate checks, each reporting its own findings.
Choosing appropriate responses to uncertainty was also important. Lighting, image quality, and alignment can affect pixel-difference measurements. A visible difference is not necessarily evidence of tampering, so the visual result is advisory. Similarly, poor registration can make a comparison unreliable, which is why PosterProof includes a refusal state.
Finally, I had to keep the scope realistic for a hackathon. Rather than attempting a universal forgery detector, I focused on a working prototype with specific checks, reproducible synthetic examples, and clearly communicated limitations.
Accomplishments I'm Proud Of
I'm proud to have turned the initial idea into a working local web application rather than stopping at a conceptual design.
The main accomplishments include:
- Implementing an image-registration pipeline that can align a photographed poster with its reference when sufficient matching evidence is available.
- Separating QR payload mismatches from potential changes in monitored visual regions.
- Introducing a conservative refusal outcome when the evidence does not support a reliable comparison.
- Building four interactive synthetic demo scenarios that make the intended behaviour easy to demonstrate and understand.
- Including automated tests, setup instructions, dependency credits, and a documented repository structure so that others can reproduce the development environment.
Most importantly, the prototype is designed to communicate what it has and has not established. It does not treat every visual difference as proof of tampering or present a successful comparison as a guarantee of authenticity.
What I Learned
Building PosterProof taught me that image comparison is more complicated than checking whether two pictures look different. Perspective, lighting, image quality, and registration errors can affect a comparison even when the poster's content has not changed.
I also learned the importance of separating different kinds of evidence. A QR payload mismatch is not the same as a visual change candidate, and insufficient evidence should lead to a refusal rather than an overconfident result.
Another lesson was the value of repeatable testing. Synthetic fixtures make it easier to reproduce known scenarios and check whether the application responds as expected. However, passing controlled tests does not establish that a system will perform reliably across real-world photographs and every possible alteration.
Finally, the project reinforced the importance of defining the limits of a technical solution. A useful verification tool should help a person make a more informed decision without implying certainty that its underlying methods cannot provide.
What's Next for PosterProof
There are several areas I would explore to make PosterProof more useful beyond its current prototype.
First, I would test it against a broader collection of photographs, including different viewing angles, lighting conditions, image resolutions, and print qualities. This would help identify where registration and visual-difference checks become unreliable.
Second, I would make monitored regions easier to configure for different poster layouts. This could let organisers select which details matter most, such as event dates, venue information, registration links, and QR codes, without relying on a single fixed example.
Third, I would improve the reporting and review workflow. Clearer explanations of alignment quality, QR decoding outcomes, and visual-difference measurements could help users understand why a result was produced and when manual inspection is necessary.
I would also expand automated tests to cover more failure cases and evaluate performance on real-world samples with appropriate permission. Any future claims about reliability would need to be supported by systematic testing rather than synthetic demonstrations alone.
The longer-term goal is to make PosterProof a more dependable review aid for event organisers and campus societies while retaining its evidence-first approach. It would remain a tool for identifying discrepancies that deserve attention, not a guarantee that a poster is authentic or that a QR destination is safe.
What's Next for PosterProof
The next step is to evolve PosterProof from a local prototype into a hosted web application that connects event organisers with the people viewing their posters.
1. An Online Poster Registration System
Event organisers and campus societies could create an account and upload their approved master poster to the platform. PosterProof would register the poster, store its reference artwork, and associate it with the relevant event details and organiser.
Each registered poster could receive a unique verification page and a dedicated verification QR code. This would give organisers a straightforward way to make their approved poster information available for public checking.
2. Public Poster Verification
People viewing a displayed poster could scan its dedicated verification QR code using their phone and open a public verification page in their browser.
The page could show the registered event information, the approved master poster, and the verification status. Where appropriate, users could also take or upload a photograph of the displayed poster so PosterProof could compare it with the registered reference.
The application could then report whether the QR payload matches, whether monitored visual regions contain potential changes, or whether the photograph cannot be compared reliably. Visual differences would remain warnings for further review rather than automatic proof of tampering.
3. Stronger Trust and Security
A key challenge would be ensuring that the verification process itself can be trusted. If an attacker replaces the original QR code, a user scanning that replacement might never reach PosterProof.
To address this, the public verification mechanism should be designed separately from the event's ordinary registration or information QR code. The platform could use a dedicated verification QR code, a recognisable official verification URL, and a unique poster identifier. Users should be able to check that they have reached the genuine verification service.
Future versions could also introduce stronger controls for organiser accounts, protection of registered reference images, and an auditable record of poster updates. The platform would need to handle uploaded images and public access securely.
4. Broader Testing and Improvements
I would expand testing beyond synthetic examples to cover real-world photographs, different lighting conditions, camera angles, print quality, and more types of poster alterations. Additional work would improve the configuration of monitored regions, explain comparison results more clearly, and evaluate how often the system produces false warnings or unreliable comparisons.
The longer-term goal is to make PosterProof a practical verification service for campus societies, event organisers, and the public. Organisers would have a way to register approved artwork, while viewers could check poster information and investigate potential discrepancies before trusting what they see.
PosterProof would remain a decision-support tool rather than a guarantee of authenticity or QR destination safety. Its purpose would be to provide clearer evidence and help people make more informed decisions.
5. Automatic Region Detection
Another future improvement would be to introduce automatic region detection for QR codes and important event information. The current prototype relies on configured regions of interest, which limits its flexibility when working with posters that have different layouts.
Future versions could automatically locate QR codes in the poster photograph and compare their decoded payloads with the registered reference. For event details such as dates, times, and venues, the system could incorporate optical character recognition (OCR) to locate and extract text before comparing it with the approved master poster.
These capabilities would reduce the need for manual region configuration and make PosterProof more adaptable to different poster designs. However, automatic detection and text recognition may produce errors, particularly when images are blurry, text is small, or lighting conditions are poor. The system should therefore communicate uncertainty and retain human review for potentially altered information.
Log in or sign up for Devpost to join the conversation.