README.md

metadata

title: Image Services LaMa
emoji: 🧩
colorFrom: blue
colorTo: indigo
sdk: docker
app_port: 7860
pinned: false
license: apache-2.0
short_description: LaMa inpainting, API gateways, and CPU OCR.

Image Services LaMa

Minimal Hugging Face Space for Stage 1/2 validation:

image + mask -> LaMa inpaint -> PNG result

This implementation mirrors the local remove-ai-watermarks LaMa path:

• Carve/LaMa-ONNX
• onnxruntime CPU execution
• padded mask ROI resized to the model square input
• paste back only masked pixels so unmasked areas remain pixel-exact

Deployment Target

This Dockerfile explicitly declares DEPLOYMENT_TARGET=huggingface, loads LaMa from Carve/LaMa-ONNX on Hugging Face, and loads MI-GAN from the Sanster GitHub Release URL. Deploy it from the canonical repository with:

.\scripts\deploy-image-services.ps1 -Target huggingface

The target is required; do not upload the repository-root ModelScope Dockerfile to this Space.

Sub2API HTTPS Gateway

The Space also exposes /v1/* as a streaming reverse proxy to the standalone Sub2API service. This gives Codex Desktop an HTTPS endpoint without changing the existing image routes.

https://flakego-image-services-lama.hf.space/v1/models
https://flakego-image-services-lama.hf.space/v1/responses
https://flakego-image-services-lama.hf.space/login

The legacy /sub2api entry redirects to /login. After authentication, the Sub2API router sends administrators to /admin/dashboard.

Configure the origin with SUB2API_ORIGIN_URL and SUB2API_ORIGIN_HOST when the defaults are no longer appropriate.

XToken Images Proxy

The Space also forwards the two image operations used by the static GPT image workspace:

POST /xtoken-images/generations
POST /xtoken-images/edits

Only these two operations are accepted. The client supplies its own XToken API key in the bearer authorization header, and request bodies are limited to 32 MiB.

OCR Service

The same Space also provides CPU OCR. It uses the rapidocr deployment profile, so it preserves the existing LaMa, Sub2API, and XToken services while keeping the additional runtime small. The other local OCR engines are not enabled in this Space profile.

On process startup, the Space preloads RapidOCR plus both watermark-removal backends: MI-GAN (fast) and LaMa ONNX (quality). A running process therefore keeps all three models in memory; an HF restart repeats this startup warmup.

GET  /ocr/health
POST /ocr/api/invoke

/ocr/api/invoke follows the unified OCR contract. Supported operations are ocr.recognize, ocr.compare, providers.status, and providers.warmup. For remote requests, provide image.base64; image.path only refers to files already present inside the container.

{
  "operation": "ocr.recognize",
  "payload": {
    "provider": "rapidocr",
    "image": {"base64": "<base64 image bytes>"}
  }
}

Successful responses use { "ok": true, "result": ..., "error": null }. Provider and input errors use the same shape with ok: false and a structured error object.

Douyin Parser

The Space also resolves public Douyin share links for the Image Services /douyin-parser/ page:

GET  /douyin/health
POST /douyin/parse

The parse request body is { "share_text": "..." }. The response returns the numeric post ID, title, cover, engagement counts, and the public playback URL from the share page's play_addr. The resolver accepts only douyin.com and iesdouyin.com URLs and has no download, transcription, comment, or account collection capability.