DupeShield: Protecting Independent Fashion Designers from Design Theft with Perceptual Hashing

https://github.com/Tazz-jpg/dupeshield-for-designers

TL;DR: I built DupeShield, a free tool that helps independent fashion designers detect when their work has been copied online. It uses perceptual hashing to compare images (even after resizing or cropping) and optionally uses Google Cloud Vision for web-scale reverse image search. Testing shows it reliably separates copied designs from unrelated ones — with mean Hamming distances of 5.4 vs 30.5. The tool is open-source and runs locally, with no ongoing subscription cost.

Abstract

Independent fashion designers generally operate with limited legal budgets and no dedicated brand protection staff, which makes the manual monitoring of online marketplaces for copied designs impractical at any meaningful scale. This report presents the development of DupeShield, a tool intended to help independent designers detect when an original design has been copied and re-listed elsewhere online. The system combines perceptual image hashing with reverse image search, allowing a candidate image to be compared either against a designer's own registry of original work or against the wider indexed web using Google Cloud Vision's web detection feature.

Built in Python using Flask and the ImageHash library, the tool is accessible through both a command line interface and a browser-based interface, so that registering a design, scanning a candidate image, and reviewing potential matches do not require specialist technical knowledge. The project situates this technical work within the wider context of intellectual property law as it applies to fashion, a field in which formal design protection is often described in the literature as weak, inconsistently enforced, and poorly suited to the pace at which trends move (Raustiala and Sprigman, 2006). It also considers the practical and legal constraints that shape any tool built on automated image comparison and web-based scanning, including the reliability of perceptual hashing under common image transformations and the legal status of collecting data from third party websites.

Testing across resized, recompressed, cropped, rotated and watermarked copies of a set of synthetic test designs showed that perceptual hashing reliably separates transformed copies of the same design from unrelated designs, with same design pairs clustering at a mean Hamming distance of 5.4 against a mean of 30.5 for unrelated pairs. The web detection component was validated qualitatively, correctly locating the original source of a test image among a number of unrelated third-party postings across several platforms. Developed independently outside of formal coursework, the project demonstrates practical competency in image processing, third party API integration and full stack web development, while engaging critically with the limits of automated tools in a domain that ultimately depends on human legal judgement rather than a similarity score alone.

List of Figures

Figure 1: DupeShield System Architecture Diagram

Figure 2: Wireframe of the DupeShield Web Interface

Figure 3: Hamming Distance Distribution, Same Design Copies versus Unrelated Design Pairs

Introduction

Online marketplaces and social media platforms have made it straightforward for anyone to sell clothing, and equally straightforward for a seller to copy someone else's design and list it as their own. For an established fashion house this is an old and familiar problem, usually met with a legal team and a monitoring budget. For an independent designer working alone or in a small studio, the same problem is far harder to address. There is no time to search every marketplace by hand, no budget for a commercial brand protection subscription, and often no clear route to enforcement even once a copy has been found, given how limited formal legal protection for fashion design is in most jurisdictions (Raustiala and Sprigman, 2006).

This report documents the development of DupeShield, a tool that gives an independent designer a practical, low-cost way to check whether their work has been copied. The system is built around perceptual image hashing, a technique that produces similar hash values for visually similar images even when one has been resized, recompressed or otherwise altered, so that a copied design can still be recognised after the kind of minor changes a reseller typically makes before re-uploading it (Zauner, 2010). A designer can register their original designs in a personal library and scan candidate images against that library at no cost and with no external dependency. For a broader check, the tool can also call Google Cloud Vision's web detection feature, which searches across the indexed web for pages where a given image, or a visually similar one, has been published.

The project sits at the intersection of two areas: the technical problem of building a reliable, low-cost image similarity tool, and the practical and legal reality that fashion design occupies an unusually weak position within intellectual property law compared with other creative industries. Both strands run through this report. The technical sections describe how the hashing and web search components were built, tested and combined into a usable application. The background and ethics sections address why fashion design protection is difficult in the first place, and what limits and risks are involved in automating any part of the monitoring process, including the legal status of collecting data from third party websites and the risk of false positives being treated as proof of copying when they are not.

The remainder of this report is structured as follows. Section 2 reviews the relevant literature and existing tools, covering fashion design and intellectual property, perceptual hashing, reverse image search, and the legal status of automated web monitoring. Section 3 sets out the aims and objectives of the project. Section 4 describes the methodology and system architecture. Section 5 details the implementation. Section 6 presents the evaluation and results. Section 7 addresses ethical considerations. Section 8 outlines future work, and Section 9 concludes.

Background and Literature Review

This section situates the project within its broader context, covering the state of intellectual property protection for fashion design, the technical foundations of perceptual image hashing and reverse image search, the legal position of automated web monitoring, and existing commercial and independent tools that address similar problems.

Fashion Design and Intellectual Property

Fashion occupies an unusual position in intellectual property law. Raustiala and Sprigman (2006) describe this as the piracy paradox: despite very little formal protection for the shape and cut of a garment, the fashion industry remains highly innovative and commercially successful, which runs counter to the usual argument that strong intellectual property rights are necessary to encourage creative investment. In their later work, Raustiala and Sprigman (2009) revisit this argument and note that copying, rather than only harming designers, can also accelerate trend cycles in ways that benefit the industry as a whole, which may partly explain why the fashion industry itself has historically been fairly relaxed about enforcement compared with, for example, the music or film industries.

In the United Kingdom, protection for fashion design is split across several overlapping regimes. Copyright under the Copyright, Designs and Patents Act 1988 can cover a printed pattern or graphic applied to a garment, provided it is sufficiently original, but the courts have traditionally been reluctant to extend copyright to the cut or silhouette of a garment itself (Lexology, 2018). Separately, unregistered design right under Part III of the same Act protects the shape or configuration of an article, arising automatically without registration, though it excludes surface decoration and lasts for a comparatively short term (D Young & Co, 2018). None of this protection is automatic in the sense of being easy to enforce. A designer still must identify the infringement, gather evidence, and in most cases fund legal action themselves, all of which is disproportionately difficult for a small or independent studio compared with a large brand with an in-house legal team.

The economic scale of the wider problem is well documented. The OECD and the European Union Intellectual Property Office estimate that global trade in counterfeit and pirated goods reached approximately 467 billion US dollars in 2021, with clothing, footwear and leather goods jointly accounting for 62 per cent of seized counterfeit goods, making fashion one of the most heavily affected sectors (OECD and EUIPO, 2025). The same report notes that small and medium sized enterprises are likely to be disproportionately affected, since they typically lack the resources to engage with enforcement agencies to the same degree as larger firms (OECD and EUIPO, 2025). This gap between the scale of the problem and the resources available to the people most affected by it is the central motivation for DupeShield.

Perceptual Hashing and Image Similarity

Perceptual hashing differs from cryptographic hashing in that it is designed to tolerate small visual changes rather than being destroyed by them. Where a cryptographic hash such as SHA-256 produces a completely different output if a single pixel changes, a perceptual hash produces a similar output for images that look similar to a human, even after resizing, recompression or minor colour adjustment (Zauner, 2010). The pHash algorithm used in this project works by converting an image to greyscale, applying a discrete cosine transform, and retaining the lowest frequency coefficients, which capture the broad structure of an image while discarding fine detail that is most likely to change under compression or resizing (Zauner, 2010). Two hashes are then compared using the Hamming distance, the number of bits that differ between them, with a smaller distance indicating greater visual similarity.

A recurring finding in the forensic and security literature is that different perceptual hashing algorithms have different weaknesses. McKeown and Buchanan (2023) compared several popular algorithms, including pHash, and found that while compression had relatively little effect on any of the tested algorithms, transformations such as cropping, rotation and mirroring had a much larger impact on hash stability, a pattern that was also confirmed independently during the digital testing carried out for this project, where cropped images consistently produced higher Hamming distances than resized, recompressed, rotated or brightness adjusted copies of the same design. This has a direct practical implication for DupeShield: a matching threshold that is set to catch cropped copies risks also matching unrelated images, so the threshold represents a genuine trade-off between false positives and false negatives rather than a value that can simply be set as high as possible.

Reverse Image Search and Web Scale Detection

Where perceptual hashing alone can only compare an image against a library the user has built themselves, reverse image search extends the same underlying idea to the scale of the indexed web. Services such as Google Cloud Vision's web detection feature accept an image and return pages on which that image, or a visually similar one, has been found, along with any other images the underlying index considers closely related. This is by far the most practical way for an individual project to approximate an internet wide search, since building and maintaining an index of that scale independently is not realistic outside of a small number of large technology companies.

This is also the underlying approach used by commercial brand protection platforms. Pixsy, for example, offers a reverse image search and monitoring service built around continuously checking a user's registered images against the web and flagging potential copyright infringements (Pixsy, n.d.). Red Points describes a similar image recognition pipeline for counterfeit detection, in which candidate listings are first filtered by category and keyword before being compared visually against a brand's registered product images, since comparing every image on the internet directly would be computationally impractical (Red Points, 2022). DupeShield's two tier design, a fast local registry check followed by an optional broader web search, mirrors this same funnelling logic on a much smaller scale, appropriate to an individual designer rather than an enterprise brand.

The Legality of Automated Monitoring

Any tool that involves collecting or scanning content from third party websites must consider the legal position of that activity, separately from whether the underlying purpose is legitimate. In the United States, the long running case of hiQ Labs v LinkedIn established that scraping data from the publicly accessible pages of a website does not, by itself, violate the Computer Fraud and Abuse Act, since that statute is concerned with unauthorised access rather than with the mere collection of information that anyone could otherwise view (Fenwick, 2022). The case eventually ended in a private settlement after LinkedIn separately established that hiQ had breached LinkedIn's user agreement and had, in places, used fake accounts to access data that was not in fact publicly available, which shows that the absence of a criminal law violation does not remove the risk of a contractual or civil claim (Fenwick, 2022).

The practical lesson for a project like DupeShield is that scanning publicly visible listing pages sits on considerably firmer ground than attempting to bypass a login wall, a paywall or an explicit access restriction, and that a website's terms of service, even where not criminally enforceable, can still create liability under contract or tort law. This project's scraper module is accordingly limited to publicly accessible listing pages and is documented as a starting point that requires the user to check the terms of service and robots.txt file of any specific marketplace before pointing it at that site in practice, rather than presenting unrestricted scraping as a safe default.

Related Work and Existing Platforms

DupeShield is a modest, individually developed project rather than a commercial platform, but it draws directly on ideas already established by existing brand protection tools. Red Points offers an enterprise scale counterfeit detection and takedown service built around AI driven image recognition and automated enforcement across marketplaces, social media and search engines (Red Points, 2022). Pixsy offers a more accessible, image owner focused service, allowing individual photographers and creators to monitor a set of registered images and pursue infringement cases on a contingency basis (Pixsy, n.d.). Both tools are aimed primarily at users who can either pay a recurring fee or share a percentage of any recovered damages, which places them out of reach for many independent designers early in their career.

DupeShield differs from these platforms in scope and audience rather than in underlying technique. It does not attempt enforcement, takedown or legal action, and it does not claim anything close to the detection coverage of a commercial platform built on billions of monthly data points (Red Points, 2022). What it does provide is a free, self-hosted starting point that an individual designer can run locally, register their own designs into, and use to perform an initial check before deciding whether a potential copy is worth pursuing further, whether that means a polite message to a seller, a formal takedown request, or simply keeping a dated record in case it becomes relevant later.

Aims and Objectives

Primary Aim

The primary aim of this project is to develop a functional, self-contained tool that allows an independent fashion designer to register original designs and check candidate images, whether from a suspected copycat listing or a routine periodic check, against both a personal registry and the wider indexed web, without requiring specialist technical knowledge or ongoing subscription cost.

Secondary Aims

● To demonstrate practical competency in image processing, specifically perceptual hashing and similarity comparison, as part of an undergraduate cyber security programme.

● To integrate a third-party computer vision API into a working application and handle its authentication, error states and quota limits appropriately.

● To build a usable web interface on top of an existing command line tool, demonstrating full stack development from backend logic through to a styled front end.

● To engage critically with the legal and ethical context surrounding automated web monitoring, rather than treating the technical capability in isolation from its real-world consequences.

Specific Objectives

Objective

Approach

Success Criterion

Build a perceptual hashing core

Implement image hashing and Hamming distance comparison using the ImageHash and Pillow libraries.

Correctly distinguishes transformed copies of the same design from unrelated designs at a sensible default threshold.

Build a local registry system

Store registered designs and their hashes in a simple, dependency free format.

A design can be registered and later retrieved and scanned against with no data loss.

Integrate reverse image search

Call Google Cloud Vision's web detection feature with a locally provided API key.

Returns exact and partial matching images and pages for a genuine test image.

Develop a command line interface

Provide register, scan, scan page and scan web subcommands with clear output.

All core functionality is usable end to end from the command line.

Develop a web interface

Build a Flask application with register, scan library and scan web panels.

A user can complete the full workflow through a browser without touching the command line.

Evaluate detection performance

Test the hashing pipeline against a set of transformed copies and unrelated images.

Measurable separation between same design and unrelated design Hamming distances.

Address legal and ethical context

Include a dedicated section situating the tool within IP law and web scraping case law.

Report includes a substantive, source supported discussion of these issues.

Scope and Constraints

● Scope: the project focuses on still image-based comparison for a single designer's own registry, plus optional web scale search. Automated enforcement or takedown submission is out of scope and is left as a manual step for the user.

● Target technique: the primary similarity technique is perceptual hashing (pHash) for the local registry, supplemented by Google Cloud Vision's web detection for the broader web search.

● Constraints: the project was developed independently outside of formal coursework, on personal hardware, with no budget beyond the free tier of the Google Cloud Vision API and using only open-source Python libraries for the core hashing pipeline.

Methodology and System Architecture

This section details the methodological approach and architectural decisions behind DupeShield. The system follows a fairly conventional layered architecture, with a thin presentation layer, in either command line or web form, sitting on top of a shared set of Python modules that handle hashing, storage and web search.

High Level Architecture

The application is organised into a small number of single purpose modules rather than a single monolithic script, so that the hashing logic, the storage logic and the web search logic can each be tested and modified independently. Figure 1 shows the high-level architecture: both the browser interface and the command line interface call into the same Flask application logic and shared modules, which in turn read from and write to a local JSON registry and, when requested, call out to the Google Cloud Vision API.

Figure 1: DupeShield System Architecture Diagram

Technology Stack

The following technologies were selected based on suitability for a small, independently developed project, community support, and prior familiarity from coursework and self-directed learning.

Component

Technology

Justification

Programming language

Python 3.12

Wide library support for image processing and web development, and familiar from prior coursework.

Perceptual hashing

ImageHash (pHash)

Well established, actively maintained implementation of the pHash algorithm described by Zauner (2010).

Image handling

Pillow (PIL)

Standard Python library for opening, resizing and processing image files.

Reverse image search

Google Cloud Vision API (Web Detection)

Provides web scale reverse image search without needing to build and maintain a search index independently.

Web scraping

requests, BeautifulSoup

Lightweight tools for retrieving and parsing publicly accessible listing pages.

Backend framework

Flask

Lightweight, easy to integrate with existing Python modules, suitable for a small self hosted tool.

Storage

JSON file

Zero configuration persistence appropriate to a single user, locally run prototype.

Frontend

HTML, CSS, vanilla JavaScript

No additional framework required for a small number of forms and a results panel.

Version control

Git

Standard practice for tracking changes during independent development.

The Duplicate Detection Pipeline (Step by Step)

The core detection pipeline, shared by both the command line and web interfaces, consists of five stages.

Stage 1: Registration. A designer supplies an original image along with their name and a title for the design. The image is hashed using pHash and the resulting hash, along with the designer's name, title and a timestamp, is stored as a new record in the local registry.

Stage 2: Candidate acquisition. A candidate image is supplied either as a local file, a direct image URL, or by scanning every image found on a given listing page.

Stage 3: Hashing. The candidate image is passed through the same pHash function used at registration, producing a directly comparable hash value regardless of the image's source.

Stage 4: Comparison. The candidate hash is compared against every hash stored in the registry using Hamming distance. Any comparison at or below the configured threshold, ten by default, is reported as a possible match, along with a confidence label of high, medium or low based on how close the distance is to zero.

Stage 5: Optional web search. If requested, the candidate image is separately submitted to the Google Cloud Vision web detection endpoint, which returns any exact or partial matching images and any pages on which the image, or something visually similar, has been found across the indexed web, independent of whether it matches anything in the local registry.

Hash Comparison and Threshold Selection

The matching threshold is the single most consequential parameter in the system. Set it too low and only near identical images, essentially the same file, are ever flagged, which misses copies that have been resized, cropped or recompressed on their way to a second listing. Set it too high and unrelated images begin to be flagged as matches, undermining the tool's usefulness by generating false alarms. A default threshold of ten was chosen following the digital testing described in Section 6, based on the observation that transformed copies of the same design in that experiment clustered well below this value while unrelated designs sat well above it, though the threshold is exposed as a configurable command line and code parameter rather than fixed, since the appropriate value will depend on the specific images a designer is working with.

Web Interface Design

The command line interface was built first, since it exercises the same underlying modules with the least additional complexity. A browser-based interface was added afterwards to make the tool usable by someone without command line experience, presenting the same registration, library scan and web scan operations as three panels within a single page, alongside a live view of everything currently in the registry. Figure 2 shows a simplified wireframe of this layout.

Figure 2: Wireframe of the DupeShield Web Interface

Development Methodology

Development followed an incremental, feature by feature approach rather than a formal methodology such as Scrum, which reflects the reality of a solo, independently developed project. Each stage of the pipeline, hashing, local storage, registry comparison, and finally web search, was implemented and manually tested in isolation before being wired into the command line interface, and the web interface was only added once the underlying modules were confirmed to work correctly end to end from the command line.

Hardware and Resource Requirements

All development was carried out on personal hardware running Windows, with no dedicated server, cloud compute, or paid software beyond the free tier of the Google Cloud Vision API. Perceptual hashing is computationally lightweight compared with, for example, training or running a neural network, so the tool runs comfortably on a standard laptop without requiring a graphics processing unit.

Implementation

Module Structure and Organisation

The final codebase is organised into the following files, each responsible for a single part of the pipeline described in Section 4.

● hasher.py: generates perceptual hashes from a local file, raw bytes, or a remote URL, and computes Hamming distance between two hashes.

● database.py: a minimal JSON backed store for registered designs, including add, list and remove operations.

● scanner.py: compares a candidate hash against every design in the registry and returns matches below the configured threshold, sorted by closeness.

● scraper.py: retrieves image URLs from a given listing page using requests and BeautifulSoup, for use with the scan page command.

● web_search.py: wraps the Google Cloud Vision web detection endpoint, handling authentication, the request payload, and parsing of the response.

● cli.py: the command line entry point, exposing register, scan, scan page, scan web and list subcommands via argparse.

● app.py, templates/index.html, static/style.css: the Flask web interface built on top of the same modules.

Key Implementation Details

The hashing module deliberately supports three input sources, a local file path, raw bytes and a remote URL, since the same underlying comparison is needed in three different contexts: registering a designer's own file, scanning a downloaded listing image, and scanning an image referenced directly by URL. Centralising this logic in one module meant the comparison behaviour only had to be written and tested once, and any later change to the hashing algorithm only needs to be made in a single place.

The registry format was kept deliberately simple, a single JSON file rather than a database, since the project only needs to support a single user working with a modest number of designs at a time. Each record stores the designer's name, a title, the source image path, the pHash value as a hex string, and an ISO timestamp. This is not intended as a production ready storage layer and the README notes SQLite as the natural next step if the tool were to be extended to support multiple concurrent users or a much larger registry.

The web search module required careful handling of authentication and error states, since a missing or invalid API key, a billing configuration issue, or an exceeded quota all surface as different HTTP error responses from the Vision API. The module raises a clear, specific error message when the expected environment variable is not set, and the calling code in both the CLI and the web interface catches request exceptions and surfaces the underlying error to the user rather than failing silently or crashing.

Technology Selection Decisions

Flask versus Django

Flask was chosen over Django for the web interface because the application only needed a small number of routes and no built-in admin panel, authentication system or object relational mapper. Django's additional structure would have added complexity without a corresponding benefit for a project of this size, whereas Flask allowed the existing command line modules to be reused directly with minimal adaptation.

JSON File versus a Relational Database

A JSON file was chosen over SQLite or another database for the initial registry, prioritising zero configuration setup over long term scalability. This was a conscious trade off, acceptable for a prototype intended for a single designer's personal use but explicitly documented as a limitation that would need addressing before the tool could reasonably support multiple users or a much larger design library.

Google Cloud Vision versus TinEye

Google Cloud Vision was selected over TinEye and Bing Visual Search primarily on the basis of cost and setup speed. Vision offers a free monthly quota sufficient for prototype level testing, whereas TinEye's API is paid only with no meaningful free tier. This decision does introduce a dependency on a Google Cloud account and billing configuration, which added noticeable setup friction during development, discussed further below.

Challenges During Implementation

Environment and Interpreter Configuration

A significant, if mundane, source of friction during setup was the difference between the Windows Store's python.exe alias and an actual Python installation. Running python from PowerShell initially opened the Microsoft Store rather than executing any code, which was resolved by using the py launcher instead, a detail that is easy to overlook but that would block a beginner from progressing at the very first step. This experience directly shaped the project's README, which documents both the py launcher fallback and the App Execution Aliases setting as an explicit troubleshooting step, rather than assuming python will simply work.

PowerShell Execution Policy

Activating a Python virtual environment on Windows requires running a PowerShell script, which is blocked by default under PowerShell's execution policy. This produced an unclear error message on first attempt and required explicitly setting the execution policy to RemoteSigned for the current user before the virtual environment could be activated. This is again the kind of environment specific obstacle that is trivial once known but can otherwise stop a beginner's setup dead, and it is documented explicitly in the project README rather than assumed as prior knowledge.

Google Cloud Vision Authentication and Billing

The most involved implementation challenge was not in the Python code itself but in correctly configuring the Google Cloud Vision API. An initial attempt to create credentials through the Cloud Console's default wizard led toward a service account and OAuth client, which is unnecessary complexity for a script-based tool that only needs a plain API key. After creating a restricted API key directly, requests still failed with an HTTP 403 Forbidden response, which was ultimately traced to no billing account being linked to the Google Cloud project, a requirement of the Vision API even within its free usage tier. Once billing was linked, the same request succeeded immediately, correctly returning exact and partial image matches and a list of third-party pages on which the test image appeared. This experience is reflected in the README's setup instructions, which call out billing linkage explicitly rather than assuming that enabling the API alone is sufficient.

Summary

The implementation stage confirmed that the core technical pipeline, hashing, local comparison, and web scale search, works reliably once correctly configured, but also demonstrated that a meaningful proportion of the practical difficulty in a project like this lies outside the algorithm itself, in environment setup, authentication, and the gap between a cloud provider's documentation and what a first-time user actually needs to do. Addressing this gap directly in the project's own documentation was treated as part of the deliverable, not a separate concern from the code.

Evaluation and Results

Digital Testing

Methodology

To evaluate the perceptual hashing component independently of any specific real-world image, a controlled experiment was run using six synthetically generated test designs, each a distinct arrangement of coloured shapes intended to stand in for a printed fabric pattern. For each design, six derived copies were produced to simulate transformations a genuine reseller might apply, whether deliberately or as a side effect of re-uploading: a resize down and back up, JPEG recompression at quality 40, an eight per cent crop with the result resized back to the original dimensions, a four-degree rotation, a brightness adjustment, and a simulated watermark overlay covering a strip of the image. Every derived copy was hashed and compared against the hash of its own original using Hamming distance. As a baseline, every pair of distinct original designs was also compared to establish the typical distance between genuinely unrelated images.

Metrics

The primary metric was Hamming distance between pHash values, following the same measure used in the perceptual hashing literature (Zauner, 2010; McKeown and Buchanan, 2023). A lower distance indicates greater similarity. Same design distances and unrelated design distances were summarised separately by minimum, maximum and mean, since the separation, or lack of it, between these two distributions is what determines whether a given threshold will work in practice.

Results

Across the thirty-six same design comparisons, distances ranged from 0 to 24 with a mean of 5.4. Resized and recompressed copies produced a distance of 0 in every case, indicating that pHash is effectively immune to these two transformations at the sizes and quality levels tested. Rotation and brightness adjustment produced small but nonzero distances, generally between 2 and 10. Cropping produced the largest distances within the same design group, ranging from 12 to 24, consistent with the finding reported by McKeown and Buchanan (2023) that cropping has a disproportionately large effect on perceptual hash stability compared with compression. Across the fifteen unrelated design comparisons, distances ranged from 20 to 38 with a mean of 30.5. Figure 3 shows the distribution of both groups.

Figure 3: Hamming Distance Distribution, Same Design Copies versus Unrelated Design Pairs

Analysis

The two distributions are clearly separated, with the highest same design distance recorded, 24 for a cropped image, still below the lowest unrelated distance recorded, 20. This suggests that, for the transformations tested here, a threshold somewhere between roughly 15 and 20 would separate every same design pair from every unrelated pair in this specific experiment. The project's default threshold of 10 is deliberately more conservative than this upper bound, prioritising a lower false positive rate over catching the most heavily cropped copies, on the reasoning that a missed match can be caught on a later manual check, whereas a false positive risks a designer wrongly accusing an unrelated seller of copying their work. This is consistent with the general trade off described in the perceptual hashing literature, where the choice of threshold reflects a deliberate balance between false positive and false negative rates rather than a single objectively correct value (McKeown and Buchanan, 2023).

Web Detection Testing

Methodology

The web detection component was validated qualitatively rather than through a large-scale quantitative benchmark, reflecting both the practical constraint of the API's free tier request quota and the fact that, unlike the local hashing experiment, there is no controllable ground truth for what exists across the entire indexed web. A test image was submitted to the Google Cloud Vision web detection endpoint through the completed application, using both the command line and the web interface, and the returned results were manually reviewed for correctness.

Results

For the test image used, the API correctly returned the original source image as an exact match, a visually similar but not identical image from a second platform as a partial match, and a further set of pages, spanning several unrelated social media and e-commerce platforms, on which the same or a visually similar image had been published, along with an accurately descriptive best guess content label. This confirms that the underlying integration, request formatting, authentication and response parsing, functions correctly and returns genuinely useful results for a real image, rather than only working against the synthetic test set used for the digital testing described above.

Limitations

This validation approach has clear limitations. A single successful test case demonstrates that the pipeline works but says nothing about the API's recall across a large or representative sample of fashion images, nor about how it performs against copies deliberately altered to evade detection, such as heavy cropping, mirroring, or overlaying a substantially different background. The API's underlying index and matching behaviour are also entirely external to this project and outside its control, meaning any future change to Google's own systems could alter results without any change to DupeShield's own code.

Discussion

The digital testing results support the choice of pHash as a fast, dependency light first pass filter, and confirm the specific pattern reported elsewhere in the literature that cropping is the transformation most likely to cause a missed match (McKeown and Buchanan, 2023). The web detection results demonstrate that the second, broader tier of the system works as intended for a genuine image, extending coverage well beyond what a designer's own manually curated registry could ever achieve alone. Compared with commercial platforms such as Red Points, which report scanning against billions of data points a month using custom trained models per protected asset (Red Points, 2022), DupeShield's detection coverage is necessarily far smaller in absolute terms, relying entirely on whatever Google's existing web index already contains rather than any bespoke crawling or model training of its own. This is an appropriate and honest trade-off for a free, individually developed tool aimed at a designer who currently has no automated coverage at all, rather than an attempt to compete directly with an enterprise grade service.

The main limitation of the current evaluation is scale. A genuinely thorough evaluation would test both components against a much larger and more varied set of real fashion images, including deliberately adversarial copies designed to evade detection, and would ideally compare DupeShield's results directly against an existing commercial tool on the same image set. This was outside the scope of what was practical for an independently developed project working within the Vision API's free tier quota and is identified explicitly as future work in Section 8.

Summary

Digital testing confirms that the local hashing pipeline reliably separates transformed copies of the same design from unrelated designs at the threshold used, with cropping identified as the transformation most likely to weaken this separation. Qualitative testing of the web detection component confirms that the broader search integration functions correctly against a real image. Together, these results support the two-tier design as a reasonable and functional approach, while making clear that both components would benefit from a larger and more adversarial evaluation than was practical within this project's constraints.

Ethical Considerations

Dual Use and Overreach Risk

A tool that automates the comparison of one image against a large number of others is, by construction, a general-purpose image surveillance capability, even when it is built with a narrow and legitimate purpose in mind. The same pipeline that lets a designer check whether their own work has been copied could, with only a change of input images, be pointed at a competitor's entire catalogue to monitor their releases or used to track a specific individual's images across the web for reasons unrelated to design protection. This is not a hypothetical concern specific to DupeShield, it is an inherent property of any accessible reverse image search capability, but it is worth stating plainly rather than only presenting the tool's intended use case.

Position Statement

This project is built and documented around a single, narrow use case, an individual designer checking whether their own registered work appears to have been copied. The registry only stores design the user themselves adds, and the web search component operates on a single image at a time rather than facilitating any kind of bulk or automated surveillance of a third party's activity. No functionality for automatically contacting, reporting or taking action against a suspected copier is included, the tool stops at presenting a possible match for the user to evaluate and act on themselves. This is a deliberate design choice intended to keep a human decision maker in the loop for every consequential action.

Responsible Use of Web Scraping and APIs

As discussed in Section 2, scraping publicly accessible pages does not by itself violate the Computer Fraud and Abuse Act in the United States, following hiQ Labs v LinkedIn, but can still create liability under a website's terms of service or under contract and tort law more broadly (Fenwick, 2022). The project's README and code comments explicitly instruct users to check a target site's terms of service and robots.txt file before pointing the scraper module at it, and the scraper itself is documented as a generic starting point rather than a tool tuned for unrestricted use against any specific platform. The Google Cloud Vision integration is used strictly within its documented API terms and free tier quota, with no attempt to circumvent rate limiting or authentication.

False Positives and the Limits of Automated Evidence

A Hamming distance below a configured threshold is a statement about visual similarity, not a legal conclusion about copying, and the two are not the same thing. Two unrelated designers can independently arrive at a similar print or silhouette, particularly for simple or common design elements, and a low distance score does not establish who created something first or whether any copying actually took place. The tool's output is deliberately framed throughout the interface and documentation as a possible match requiring human review, with an explicit confidence label rather than a binary yes or no verdict, precisely to avoid a user treating an automated similarity score as if it were proof.

Data Protection and Third-Party Content

Registering a design in the local registry stores an image the user themselves supplies, which does not raise the same concerns as processing another person's personal data. The web search feature, by contrast, does return links to and information about third party content that the user does not own, including social media posts that may be associated with an identifiable individual seller. This information is only ever displayed to the user themselves within their own local session, is not stored persistently beyond the current registry file, and is not shared with or sold to any third party, which keeps the project's data handling reasonably conservative relative to what a fuller monitoring product might otherwise be tempted to build.

Conclusion

The ethical position taken in this project is that automated similarity detection is a legitimate and useful starting point for an under-resourced designer, provided it is clearly bounded, framed as advisory rather than conclusive, and kept separate from any automated enforcement action. The technical capability built here is modest in scale compared with commercial platforms, but the same caution around scope, evidence and human oversight would need to apply even more carefully were the project ever extended toward the kind of broader, always on monitoring that a commercial brand protection service provides.

Future Work

Combined Registry and Web Fallback Scanning

The current command line and web interfaces expose the local registry scan and the web scan as entirely separate operations. A natural next step is to combine them into a single scan command that checks the local registry first, since it is free and near instant, and only calls the Google Cloud Vision API if no local match is found, reducing unnecessary API usage against the free tier quota.

Batch Registration and Evidence Logging

Registering designs one at a time is workable for testing but impractical for a designer with an existing catalogue of dozens or hundreds of pieces. Supporting batch registration from a folder of images would remove this friction. Separately, saving a timestamped record, ideally including a screenshot and the matched URL, whenever a match is confirmed would give a designer something closer to genuine evidence if a dispute were ever pursued formally, rather than only an in-session result that disappears once the browser is closed.

Confidence Threshold Tuning with Labelled Data

The default threshold of ten used in this project was set following the digital testing described in Section 6, but that testing used a relatively small, synthetic image set. A worthwhile extension would be to collect a larger set of genuine, labelled example pairs, real copied designs and real unrelated designs from actual marketplace listings and use that data to tune the threshold more rigorously, potentially supporting different thresholds for different types of image content.

Similarity Beyond Perceptual Hashing

Perceptual hashing is effective against literal copies but is not designed to catch a knockoff that reproduces the general style or silhouette of a design using a different photograph entirely. Investigating a complementary approach, such as a learned image embedding produced by a pretrained convolutional network, could allow the tool to flag stylistically similar designs that a strict pixel level hash would miss, at the cost of additional computational complexity and a less interpretable similarity score.

Marketplace Specific Scraper Integrations

The current scraper module is intentionally generic, pulling every image from a given page. Tuning dedicated selectors for specific marketplaces that a designer is likely to want to monitor would substantially improve signal to noise, at the cost of needing separate maintenance whenever a target site changes its page structure and would need to be developed and used in line with the legal and terms of service considerations discussed in Section 7.

Notification and Monitoring Automation

The current tool is entirely on demand; a designer has to actively run a scan. A scheduled job that periodically re-runs a web search for each registered design and only notifies the user when a genuinely new match appears, rather than repeating results already seen, would move the tool from a manual utility toward something closer to lightweight, ongoing monitoring, while still keeping any actual enforcement decision firmly in the designer's own hands.

Conclusion

This project set out to build a functional, accessible tool that helps an independent fashion designer detect when their original work has been copied and listed elsewhere online. That aim was met. A working application was built in Python using the ImageHash library for perceptual hashing and the Google Cloud Vision API for web scale reverse image search, exposed through both a command line interface and a Flask based web interface. Digital testing across a controlled set of transformed image copies confirmed that the hashing pipeline reliably distinguishes same design copies from unrelated designs, and a real-world test of the web detection component confirmed that the broader search integration correctly locates genuine matches across independent third-party platforms.

Technically, the project provided direct experience in image processing, third party API integration, and full stack web development, and in the less glamorous but equally real skills involved in debugging environment configuration issues that have nothing to do with the underlying algorithm, from a shadowed Python interpreter to a missing billing account. Contextually, researching the background for this report clarified just how weak formal legal protection for fashion design actually is in practice, which reframed the project's purpose away from being a legal solution in itself and toward being a practical, evidence gathering first step that a designer can take before deciding whether formal action is worth pursuing.

The project also reinforced, through direct implementation rather than only through reading about it, that any tool capable of comparing images at scale carries a dual use character that must be addressed explicitly rather than assumed away. Keeping the tool's scope narrow, advisory rather than automatically actionable, and transparent about its own limitations was treated as a core design requirement throughout, not an afterthought added to the final report. Future work would extend both the technical capability, particularly around combined scanning, evidence logging and threshold tuning on real data, and the honesty of the tool's own claims about what a match does and does not prove, since the value of a project like this ultimately depends on a designer being able to trust what it tells them, not simply on how many matches it can find.

References

D Young & Co, 2018. Design rights in the UK. [online] Available at: https://www.dyoung.com/en/knowledgebank/articles/ukdesignlaw [Accessed 24 July 2026].

Fenwick, 2022. HiQ Labs Scrapes by Again: The Ninth Circuit Reaffirms that Data-Scraping Does Not Violate the CFAA. [online] Available at: https://www.fenwick.com/insights/publications/hiq-labs-scrapes-by-again-the-ninth-circuit-reaffirms-that-data-scraping-does-not-violate-the-cfaa-1 [Accessed 24 July 2026].

Google Cloud, n.d. Detect web entities and pages (Web Detection). [online] Available at: https://cloud.google.com/vision/docs/detecting-web [Accessed 24 July 2026].

Lexology, 2018. How intellectual property rights can protect fashion products in the UK: now and post-Brexit. [online] Available at: https://www.lexology.com/library/detail.aspx?g=7cfe928e-6972-4a1c-9f3b-e06d39c3ee7a [Accessed 24 July 2026].

McKeown, S. and Buchanan, W.J., 2023. Hamming distributions of popular perceptual hashing techniques. Forensic Science International: Digital Investigation, 44, p.301509.

OECD and EUIPO, 2025. Mapping Global Trade in Fakes 2025: Global Trends and Enforcement Challenges. Paris: OECD Publishing.

Pixsy, n.d. Reverse Image Search and Copyright Monitoring. [online] Available at: https://www.pixsy.com/monitor [Accessed 24 July 2026].

Raustiala, K. and Sprigman, C., 2006. The Piracy Paradox: Innovation and Intellectual Property in Fashion Design. Virginia Law Review, 92(8), pp.1687–1777.

Raustiala, K. and Sprigman, C., 2009. The Piracy Paradox Revisited. Stanford Law Review, 61(5), pp.1201–1225.

Red Points, 2022. Image recognition as a brand protection technology. [online] Available at: https://blog.redpoints.com/en/image-recognition-as-brand-protection-technology [Accessed 24 July 2026].

Zauner, C., 2010. Implementation and Benchmarking of Perceptual Image Hash Functions. Master's thesis. Upper Austria University of Applied Sciences.