From capture to a BGT report
A public technical overview of the evaluation lifecycle.
Abstract
BGT turns original photographs of a collectible card into an independent visual condition estimate. This note describes the observable process: preparing both sides, submitting an evaluation, following its status and receiving a private report or an actionable recovery outcome. Card identity and visible condition are distinct parts of the result. A completed evaluation uses one G; recapture requests and terminal failures refund its reservation.
Computer vision, image measurement and AI
BGT uses a layered evaluation process. Image measurements and capture checks assess whether the available photographs provide usable evidence; AI-assisted analysis contributes to the condition estimate. These are complementary parts of the system.
Our engineering is informed by published work in computational photography and image quality assessment. The references below provide scientific context, not a specification of our implementation, a claim that we reproduce those systems, or independent validation of BGT grading accuracy. Internal methods and calibration remain private.
- Petschnigg et al. (2004): Digital Photography with Flash and No-Flash Image Pairs — complementary observations under different lighting.
- Pertuz, Puig and Garcia (2013): Analysis of focus measure operators for shape-from-focus — image focus measurement and its dependence on acquisition conditions.
- Google Research: HDR+ burst photography dataset — research context for multiple observations and mobile image quality.
1. The service at a glance
Every report starts with your card.
Original photos. Visible evidence. An independent estimate.
Conceptual illustration, not a real report or an internal system diagram.
Computer vision and AI, working together.
BGT combines image measurements, capture checks and AI-assisted evaluation. Focus, exposure and geometry help select useful evidence before analysis.
Capture originals underpin the evaluation. Presentation cutouts and reduced-glare viewer images do not replace that evidence.
Our approach draws on techniques studied in computational photography and image analysis. It is an independent BGT estimate: scientific references do not certify product accuracy.
-
Capture
Front and back, with the complete card visible.
Sample artwork. Use your original photos.
Front 
Back Original photos are the evidence. Catalog artwork cannot replace them.
-
Prepare & submit
Review both photos and confirm the evaluation.
Preparation uses no tokens. An accepted submission reserves 1 G; an identical retry retains the original request.
-
Evaluate
Identity and condition answer different questions.
- Which card?
- Identity and printing, when they can be resolved.
- What is visible?
- Visible centering, corners, edges and surface.
Unresolved identity is not a defect. Reflections and hidden areas limit what can be concluded.
-
Retrieve
Follow the status and open the report when available.
The estimate, observations and limitations remain private. Sharing is a separate action by the owner.
Report completed
The evaluation consumes 1 G. You receive an independent BGT estimate.
1 G consumedNew photos needed
The reservation is refunded. Repeat the requested capture and submit a new evaluation.
1 G returnedTerminal failure
The reservation is refunded. A lost connection alone does not confirm failure: check status first.
1 G returned2. Evidence and scope
The input is a set of original photographs covering the front and back of the same card, submitted under the active capture contract. The card should be fully visible with space around its edges. An image of a catalog printing may help describe identity, but it cannot establish the condition of the physical card being evaluated.
Preparation checks the submitted images and prepares a capture for review. Acceptance at this stage does not guarantee a completed report: a later evaluation can still require clearer evidence. Missing required images must be corrected before submission; the client should never substitute a duplicate side or a blank image.
3. Identity, condition and presentation
- Identity
- Which card and printing can be established from the available information? An unresolved identity is preserved as uncertainty, rather than treated as physical damage.
- Condition
- What can be observed about centering, corners, edges and surface? Observations are limited by the evidence. A reflection, an obscured region or an area marked for review does not, by itself, establish a defect.
- Presentation
- Cutouts, reduced-glare previews and interactive viewers help people inspect or display a card. They do not restore the physical object, certify authenticity or prove the absence of damage. Keep the original evidence.
The result combines an estimate with observations and limitations. Catalog identity, visual condition and presentation should remain distinct in your interface, so that an attractive preview is never mistaken for stronger evidence.
4. A recoverable request lifecycle
Prepare the photos first, then submit the selected capture revisions with one stable request identifier. After acceptance, follow the returned status URL. A delayed response is not a new evaluation: recover the original request before asking the user to submit again.
| Situation | Client action | G balance |
|---|---|---|
| Photo preparation | Review both sides; correct rejected input. | No reservation. |
| Submission accepted | Keep the request identifier and follow status. | 1 G reserved. |
| Report completed | Present the available report and its limitations. | 1 G consumed. |
| Recapture requested | Explain the requested correction; use new captures for a new evaluation. | Reservation refunded. |
| Terminal failure | Show the failure and an appropriate recovery action. | Reservation refunded. |
| Connection lost | Read status or retry the identical submission with the same identifier. | Do not infer settlement; read tokenState. |
Read the returned status and token state as the authority. The diagram describes product outcomes, not literal status strings. An identical retry does not create a second charge; changing a submission while reusing its identifier is a conflict.
5. Integration map
-
GET /v1/gradings/contractRead the current capture and product requirements. -
POST /v1/gradings/photosPrepare the front and back with the same request identifier. -
POST /v1/gradingsSubmit the selected revisions and reserve one G. -
GET /v1/gradings/{id}Retrieve status and the available result with the same project's key.
Keep production credentials on your server. Use the public integration contract for exact
fields, permissions, limits and retry behavior. Poll no more frequently than every 15
seconds and respect Retry-After.
6. Interpretation and limitations
BGT is an independent estimate, not an official certification, an authenticity determination or a promise of a professional grading outcome. Photographs cannot establish everything a physical examination can. Lighting, focus, glare, sleeves and occlusion can affect what is visible; uncertainty should be preserved rather than replaced with an invented conclusion.
This note documents service behavior. It is not a peer-reviewed study or a benchmark, and it does not assert a measured accuracy rate, detection guarantee or fixed turnaround time. Game and catalog coverage varies; consult the current game directory and the API contract before enabling a workflow.
Reports and evidence are private. A public card or collection link requires a separate owner action and does not make original private files public.