---
name: photo-screen-ppt-replica
description: >
Reconstruct editable PowerPoint slides from photos or screenshots of large-screen presentations. Use when the user asks to replicate a numbered photo, crop and perspective-correct a screen, OCR slide text, convert photographed PPT content into an editable PPTX, or says things like "replicate photo 12", "photo to editable PPT", "复刻照片", "识别大屏PPT", or "把照片里的PPT转成可编辑PPT". The workflow verifies the exact source photo, asks before using external OCR or image APIs, rebuilds readable text and non-complex structures as movable PowerPoint objects, forbids full-slide screenshot backgrounds, allows bounded image assets only for genuinely complex or unreadable regions, and reports object-count validation.

Photo Screen PPT Replica

Use this skill to rebuild the presentation shown inside a photo as an editable .pptx slide. The goal is object-level editability: text is real PowerPoint text, simple diagrams are native shapes, and only genuinely complex or unreadable visual regions remain as bounded image assets.

Inputs

Accept any of these inputs:

• A numbered photo name such as photo 12, 12.jpg, 照片12, or 复刻照片12.
• An explicit source image path.
• A folder plus a photo number.
• Optional output folder and output filename.

Resolve paths in this order:

1. Use the exact path provided by the user.
2. If the user provides a workspace folder, look for photos/, photo/, images/, 照片/, or the workspace root.
3. If only a number is provided, search common image extensions: .jpg, .jpeg, .png, .webp, .bmp.
4. If multiple files match, ask the user to choose the source photo before rebuilding.

Never assume a private local path. Never hard-code a user name, drive path, API key, endpoint, or credential into outputs or skill files.

Required Companion Workflow

If the image-to-editable-ppt skill or an equivalent editable-PPT workflow is available, use it for its OCR, object-source decisions, reconstruction, and validation rules. This skill is stricter when it forbids full-slide backgrounds, large non-complex image crops, invented objects, and OCR mojibake.

OCR And API Policy

Before calling any external OCR or image backend, ask or confirm that the user allows uploading the task-local corrected screen image for OCR/asset processing. The upload scope must be limited to the current page image, prompts, masks, and required reference images.

Support these modes:

• ask: ask the user what OCR/API method to use.
• paddleocr: use the user's configured PaddleOCR token after consent.
• local: use local OCR or manual visual reading only.
• none: do not use OCR; rely on manual reading.
• custom: use a user-provided command or API description.

If no OCR/API is configured, continue locally when practical, but clearly report that OCR was not used and text fidelity may be lower.

Workflow

1. Locate and verify the exact source photo.
2. Identify the large-screen presentation area and state the visible slide title or section.
3. Crop and perspective-correct the screen into a current-run output path such as output/screen_rectified_XX_correct/XX_screen_rectified.png.
4. Run OCR if permitted and available. Treat OCR as advisory, not authoritative.
5. Build a full visual inventory from the original photo and corrected screen: title, body text, numbers, tables, cards, flows, arrows, labels, footers, logos, diagrams, chart areas, and visual assets.
6. Decide object sources before rebuilding:
   - Native editable text for readable text.
   - Native shapes for simple/non-complex structures.
   - Bounded image assets only for genuinely complex or unreadable regions.
7. Rebuild the slide as an editable .pptx and save it to the requested output folder.
8. Export a preview and validate the result.
9. Report the output path, source path, corrected image path, OCR mode, upload status, object counts, and known limitations.

Hard Requirements

• Do not use the full source photo or full corrected screen as a PPT background.
• Do not use large-area source-image crops to bypass editable reconstruction for non-complex visuals.
• Rebuild readable text, lines, rectangles, brackets, arrows, connectors, diamonds, triangles, circles, homePlate/direction blocks, legends, labels, level marks, ratios, process nodes, architecture nodes, footer information, section numbers, meeting marks, tables, KPI cards, ranking lists, simple charts, matrices, and workflow diagrams as movable/editable PPT objects.
• Treat tables, KPI cards, ranking lists, bar charts, line charts, pie/donut charts, triangle or stair-step diagrams, matrices, process bands, swimlanes, architecture boxes, and simple dashboards as non-complex when their structure is visually legible.
• Treat illustrations, anime/cartoon artwork, photos, dense screenshots, detailed logos/icons, dense external report captures, maps/heatmaps, and unreadable chart internals as complex assets only when they cannot be reliably decomposed without guessing.
• Do not invent extra frames, arrows, process nodes, labels, UI screens, explanatory chart cards, decorative lines, or guessed data.
• Do not recreate projector/camera scanlines or moire bands. Full-slide horizontal stripes caused by photographing the screen are artifacts, not slide objects.
• Keep source-like font hierarchy. Prefer stable levels: title 24/20, section 16/15/14, body 12/10/9, footer/source 6.5-8.
• Preserve source-like colors and emphasis. Avoid converting every page into a generic blue-white style.
• Prevent overlap and clipping. Long text must wrap within the same visual area as the source.
• Extract PPT text before delivery. If the output contains repeated ?, mojibake, replacement boxes, or obviously wrong Chinese/English caused by OCR or encoding failure, the build fails and must be regenerated or manually corrected.

Reconstruction Standard

Read references/replication-standard.md before rebuilding. It records the practical quality rules learned from repeated corrections: when to use native objects, when to allow a bounded image asset, how to handle data-heavy pages, flowcharts, training-card pages, exploration-list pages, and comparison pages.

Helper Script

Use scripts/rectify_screen.py for local first-pass cropping and 16:9 correction. It does not call OCR, does not use network access, and does not upload images.

Example:

python scripts/rectify_screen.py photos/12.jpg --out output/12_screen_rectified.png --json

Manual crop example:

python scripts/rectify_screen.py photos/12.jpg --out output/12_screen_rectified.png --box 0,120,4032,2800 --json

Final Report

Include:

• Final PPTX path.
• Source photo path.
• Corrected screen image path.
• Visible slide title or section.
• OCR mode used and whether external upload was used.
• Whether a full-slide background exists.
• Local image count.
• Text box count.
• Native shape count.
• Connector/line count.
• Whether repeated ?, mojibake, overlap, color drift, or invented objects were found.
• Any remaining uncertainty caused by blur, occlusion, or unreadable source text.