All guides

Dance photography6 min read

How to organize a dance competition photo gallery

Design a dance competition gallery around dancers, couples and review states so customers can find relevant action photos without browsing one giant timeline.

A dance competition photo gallery is not simply a folder placed on the web. It is the customer-facing end of a production system: several cameras, thousands of action frames, changing heats, repeated costumes, partnerships and uncertain visual matches all have to become a route that a dancer can understand.

The design question is therefore not “Which gallery theme looks best?” It is “What is the shortest defensible path from an authorised photograph to the right reviewable group?” The answer should be planned before the first card is ingested.

This guide is a method for photographers and event teams evaluating that workflow. It does not assume that a particular storefront, matching signal or sales feature is available in every product or plan.

Start with the person who has to find a photo

A capture-time timeline is useful to a photographer who remembers when a heat happened. It is much less useful to a customer who remembers a partner, a style and a costume. A practical gallery can preserve chronological order while offering an additional participant-centred route.

Write down the questions a dancer is likely to answer:

  • Which competition was this?
  • Did I dance solo, with a partner or in a formation?
  • Which style, session or category was it?
  • Which competitor number, roster entry or photo group is mine?
  • What should I do if a suggested group contains the wrong dancer?

That final question matters. A gallery structure must support correction, not just discovery.

Choose an information architecture

The right hierarchy depends on how the event is run. These are useful starting patterns:

StructureWorks well whenMain risk
Event → day → session → heatThe schedule is reliable and customers know their heatA customer may not remember the time
Event → style → dancer or coupleParticipant discovery is the main taskNames and partnerships need careful handling
Event → category → competitor numberNumbers are consistently visible and rosteredTurned bodies, occlusion and number changes create gaps
Event → reviewed photo groupVisual grouping is available and an operator confirms itUnreviewed suggestions can leak into publication

A hybrid structure is usually stronger than forcing one signal to solve everything. Keep the schedule for context, the roster for labels and a reviewed visual group for discovery. Do not flatten those sources into one unexplained “AI match”.

The ballroom Person ReID case study explains why motion blur, occlusion and similar costumes make this domain unusually demanding. Use the Person ReID guide for the crop-to-ranking workflow and the general comparison for the boundary with face recognition and tracking.

Build a signal stack, not a magic button

Competition photos contain several imperfect signals:

  1. Roster context. A registration or heat list narrows who could plausibly appear.
  2. Capture context. Time, camera and session metadata narrow the relevant part of the shoot.
  3. Visible identifiers. A competition number can be read manually or by a separate OCR process when it is legible.
  4. Face cues. A face-search system may help when the face is sufficiently visible and the deployment is justified.
  5. Full-body appearance. Person ReID can rank crops with similar clothing, texture and body appearance, including frames where a dancer looks away.
  6. Human judgement. An operator resolves the cases in which signals disagree.

Each signal has a failure mode. Numbers fold or disappear. Faces turn away. Two couples wear near-identical outfits. A costume change can separate photographs of the same dancer in appearance space. The gallery should retain enough context for a reviewer to understand why a suggestion was made.

For an event-specific comparison of facial and full-body retrieval, read face search vs Person ReID for event photos.

Separate matching from publication

An appearance score is not a publishing permission and a nearest neighbour is not a confirmed identity. Use explicit workflow states:

StateMeaningCustomer visibility
UnprocessedNo grouping attempt has completedHidden
SuggestedOne or more candidate groups existHidden
Needs reviewEvidence is ambiguous or conflictingHidden
ConfirmedAn authorised reviewer accepted the assignmentEligible according to publication rules
Rejected or correctedThe suggestion was wrong or movedHidden from the incorrect group

This boundary lets the production team work quickly without turning uncertainty into a customer-facing mistake. The operational pattern is covered in human review for AI photo matching.

Design the customer route

Once assignments are reviewed, the gallery still has to be usable. Test it on a phone and ask a person who did not build the system to find a specific dancer.

A clear route normally includes:

  • an event name and date that match the programme;
  • a small number of meaningful categories rather than production folders;
  • a participant, couple, heat or number lookup appropriate to that event;
  • a visible way to report a wrong or missing grouping;
  • clear preview, download, print and usage terms;
  • accessible labels, keyboard navigation and readable controls;
  • an explanation of whether results are complete, reviewed or still being added.

Avoid exposing raw cluster IDs, similarity scores or camera filenames to customers. Those are production details, not navigation language.

If the gallery will support purchases, plan the catalogue and fulfilment separately. How to sell dance competition photos online covers product choices, preview policy and post-order checks without assuming a particular commerce implementation.

Treat privacy as a workflow requirement

A password on a giant gallery is not the same as purpose limitation. Decide who can access each view, how long photographs and derived data remain, how a person exercises their rights, and what happens when a group is corrected or deleted.

Face and appearance matching also require a separate assessment from the ordinary act of taking a photograph. An encrypted or unnamed vector is not automatically anonymous. The GDPR guide for Person ReID in event photography lays out the questions to take to privacy and legal reviewers.

For competitions involving children, vulnerable participants or mixed public and private spaces, make those reviewers part of planning rather than a final launch check.

Pre-publication checklist

Before opening a gallery, verify:

  • Event, session and category labels match the official programme.
  • Photographer clocks and imports are reconciled.
  • Roster changes and partnership changes are reflected.
  • Suggested visual groups have an explicit review state.
  • A sample of confirmed groups has been checked across cameras and sessions.
  • Similar costumes, occluded dancers and costume changes have been inspected.
  • Wrong assignments can be rejected, moved, merged and split.
  • Customer access, retention, correction and deletion paths are documented.
  • Preview and purchase terms are understandable on mobile.
  • The team knows who handles missing-photo and wrong-person reports.

Evaluate the workflow before choosing the tool

Run a representative past competition through the proposed structure. Include the difficult images, not only portfolio selections. Measure whether a reviewer can correct groups, whether a dancer can reach relevant photographs, and whether deletions propagate to every view.

PolyReID is designed around offline event-photo organisation and human review, but the current product pages remain the source of truth for available capabilities. If you are evaluating it for a competition workflow, compare the documented options on the pricing page and validate the exact path you need before committing an event.