Rebuild editable ppt from image

Rebuild Editable PPT From Image

Rebuild the supplied flattened image as a faithful layered slide. Treat this as reconstruction, not redesign.

Start correctly

1. Read the presentations skill completely before creating or editing a PPTX.
2. Read the imagegen skill completely when using generative inpainting to make the clean background.
3. Announce that this skill is being used and that it enforces a layered reconstruction and visual-QA loop.
4. Freeze the source before editing:
   • Copy it into the task work directory.
   • Record its native width, height, absolute source path, and SHA-256.
   • Never modify the source copy.
5. Use a task-local work/ directory for intermediate assets and an outputs/ directory for user deliverables.
6. If the user asks for a public repository, synthetic demo, README visual package, or downloadable fixture, read references/public-demo-packaging.md before producing public assets.
7. If the source contains rectangular panels, rounded cards, glass frames, pills, dividers, or continuous section boxes that must remain editable, read references/vector-frame-conversion.md before producing the background or slide.

Apply the three-family contract and explicit z-order

Keep three editable object families: one clean background bitmap, replaceable images, and native text/shapes. Build them in this fixed z-order:

1. Clean background bitmap
   • Keep only fixed atmosphere, scenery, continuous textures, non-editable glows, and decorative effects.
   • Remove every page-level text item and every image that the user expects to replace.
   • Remove simple rectangular/rounded frames, panel fills, pills, dividers, and connectors whenever the user expects them to remain editable.
   • Ensure removed elements leave no duplicate text, ghosting, silhouettes, panel residue, or rectangular patches.
2. Native structural shapes below content
   • Rebuild editable panels, cards, glass frames, image wells, pills, dividers, and anchored connectors as PowerPoint shapes.
   • Name editable frames 形状_框_<区域>_<名称> and other structural objects 形状_<类型>_<区域>_<名称>.
   • Add large outer panels first, then internal frames/dividers, then connectors.
3. Replaceable image objects
   • Create one image object per meaningful product, photo, diagram, simulation, or technical illustration.
   • Preserve the source crop, aspect ratio, clipping, position, and size.
   • Use transparent cutouts for floating objects over nonuniform backgrounds.
   • Name objects 图片_<区域>_<名称>_可替换.
4. Native text and foreground shapes
   • Rebuild all page-level titles, labels, captions, and annotations as editable text boxes or PowerPoint shapes.
   • Keep text that is inseparable from a technical diagram inside that image unless the user explicitly asks to reconstruct it.
   • Name objects 文本_<区域>_<名称> or 文本框_<区域>_<名称>.

Deleting any foreground object, including a frame, must reveal a clean, plausible background with no duplicate content.

Inventory before building

Inspect the source at native resolution and prepare three manifests when editable frames are present:

• Image manifest: id, object name, x, y, w, h, crop mode (rect or vision), clipping notes, z-order, and expected replacement behavior.
• Text manifest: exact text, x, y, w, h, typeface, size, weight, color, alignment, line spacing, and whether the text is page-level or embedded in an image.
• Frame manifest: object name, geometry, x, y, w, h, corner radius, fill/gradient stops, transparency, stroke, shadow, highlight, z-order, and whether a connector must anchor to it.

Use pixel coordinates on a slide canvas that matches the reference pixel dimensions. Do not estimate positions in inches and convert back.

Group the manifests by visual region, not by arbitrary processing order.

Produce the clean background

Prefer an image edit that removes text and replaceable images while preserving the original fixed scenery and structure.

Use these rules:

• Instruct the editor to preserve the supplied image's exact composition, palette, lighting, panel geometry, connectors, and scenery.
• Ask only for removal and inpainting; do not ask for a new design.
• When panels will be converted to native shapes, instruct the editor to remove their fills, borders, dividers, labels, and connectors while preserving the continuous scene behind them.
• Treat the generated result as a donor background when it drifts from the source.
• Restore untouched fixed decorations from the source where necessary.
• Composite donor pixels by complete logical regions such as the sky, a panel interior, or a product plinth. Avoid many small hard rectangular patches that create seams.
• Never leave the original flattened image hidden behind the editable layers.

If inpainting changes important fixed geometry, repair only the affected region or generate a better donor. Do not compensate by placing the original composite underneath.

Extract replaceable images

Crop foreground images from the original reference at their exact native coordinates.

Use scripts/extract_layers.py with a JSON manifest for deterministic crops. Example:

python3 scripts/extract_layers.py \
  --source reference.png \
  --manifest image-manifest.json \
  --out-dir assets/layers \
  --vision-mask-bin work/foreground-mask

For floating products over sky, glow, grass, or other varying backgrounds:

1. Compile scripts/foreground-mask.swift on macOS:

   swiftc scripts/foreground-mask.swift -o work/foreground-mask
   

2. Mark the layer with "mode": "vision" in the image manifest.

3. Inspect the alpha edge at 100% and 200%.

Do not use flood-fill or a simple color key for reflective or glowing products. Those methods commonly preserve sky chunks or erase highlights. If Vision cannot identify the object, use a carefully prepared manual mask or a targeted image edit; do not silently fall back to a bad rectangular crop.

Panel-internal images may remain rectangular when the original visibly uses rectangular or rounded-rectangle clipping.

Rebuild the slide

Use the presentation skill's required library and helpers.

1. Set the slide canvas to the reference width and height or an equivalent 16:9 coordinate system with exact proportional mapping.
2. Add one clean background image covering the full canvas.
3. Rebuild panels and frames from the frame manifest, following references/vector-frame-conversion.md.
4. Add foreground images from the image manifest at exact x/y/w/h.
5. Add editable text from the text manifest above the images.
6. Recreate simple page-level pills, rules, label boxes, and arrows as native PowerPoint shapes.
7. Use real anchored connectors for relationships that must survive object movement.
8. Preserve the original color hierarchy, spacing, alignment, line breaks, and optical balance.
9. Add source provenance to slide notes:
   • original path or supplied filename;
   • source SHA-256;
   • statement that foreground crops derive from the supplied reference;
   • note that native text rendering may differ slightly from the flattened source.

Do not add new facts, labels, images, decorative elements, or claims.

Run the production and review committees

Use at least two rounds and at most four. Stop when all hard gates pass and remaining differences are only expected text-rendering antialiasing or similarly immaterial variation.

Production committee

For every round record:

• one round objective;
• elements that may change;
• elements that are frozen;
• inputs and scripts used;
• expected acceptance result.

Change no more than three high-impact issues per round.

Review committee

Render the actual PPTX and compare it with the reference at native size. Read references/qa-gates.md for scoring, vetoes, comparison methods, and termination rules.

Round 1 should prioritize:

• background cleanliness;
• object count and editability;
• gross positions and sizes;
• editable-frame conversion, rectangle seams, and ghost content.

Round 2 should prioritize:

• transparent edges;
• text metrics and baselines;
• real Office/WPS contrast;
• residual local differences.

Do not declare a pass from the construction preview alone.

Validate mechanically

Run all validation required by the presentations skill, including rendering every slide and the slide overflow/load test.

Also run:

python3 scripts/validate_layered_ppt.py output.pptx \
  --expected-slides 1 \
  --expected-foreground-images <count> \
  --min-text-shapes <count> \
  --min-editable-frames <count>

The validator checks:

• slide count;
• exactly one named clean background on each slide;
• replaceable foreground names and suffixes;
• minimum editable text-shape count;
• minimum editable rectangle/glass-frame count;
• duplicate object names;
• absence of a hidden full-slide reference image under the reconstructed layers.

For a public demo repository, additionally run:

python3 scripts/audit_public_fixture.py \
  --root <repository-root> \
  --max-file-mb 10 \
  --forbid "<task-specific private term>"

The audit checks local Markdown links, public file sizes, image decoding, absolute user paths, clipboard filenames, task-specific forbidden terms, and matching content inside PPTX XML.

Inspect the rendered preview at 100% and 200%. Open the final PPTX in PowerPoint or WPS and verify:

• the slide loads;
• all pictures are present;
• no fonts are missing or substituted unexpectedly;
• title and caption contrast is acceptable;
• the background, an editable frame, a text box, an image, and a connector can each be selected independently;
• the key objects can be edited and replaced.

If the real application cannot be opened, state the reason and describe the substitute validation.

Report similarity honestly

Aim for:

• object boundaries and text baselines within 2 source pixels;
• no visible seams, white halos, ghost text, duplicated images, or background holes;
• SSIM at least 0.97 when the same fonts and renderer are available.

Do not claim pixel-perfect similarity without measuring it. A flattened reference and native editable text can differ because of font substitution and antialiasing. Report the measured result and local exceptions.

Deliver

Return only:

• the layered .pptx;
• an actual-render .png preview.

Keep diagnostics, manifests, masks, committee notes, and intermediate renders in the task work directory unless the user asks for them.

When the user explicitly asks for a public demonstration or repository packaging, follow references/public-demo-packaging.md instead. Publish only a synthetic fixture, its validation evidence, reviewed README media, and licensing/provenance records. Never publish the user's source page merely to demonstrate the skill.

In the final handoff state:

• the output filenames;
• the foreground image count;
• the editable text/shape count;
• the editable rectangle/glass-frame count;
• the review rounds completed;
• the actual application opened and what was observed;
• any remaining rendering or font caveat.