README.md

---
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:

```text
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:

```powershell
.\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.

```text
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:

```text
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.

```text
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.

```json
{
  "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:

```text
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.