RedInk

Converts a user-provided text topic into a structured content outline by routing requests through pluggable AI text generation clients (Google GenAI, OpenAI-compatible APIs). The system uses a provider configuration abstraction layer to support multiple LLM backends, with prompt engineering that enforces JSON schema compliance for downstream image generation. Implements retry mechanisms and error handling to ensure reliable outline generation even with transient API failures.

Generates 6-9 styled images from outline content by orchestrating multiple image generation backends (Google GenAI, Banana.dev Nano Pro, OpenAI-compatible APIs) through an abstraction layer. Each image is generated with embedded Chinese text, consistent visual design across the series, and optional reference image conditioning. The system applies image compression and optimization post-generation to reduce file sizes while maintaining quality for social media distribution.

Embeds Chinese text directly into generated images during the image generation phase, using LLM-based text generation (outline content) and provider-specific text rendering capabilities. The system generates Chinese text via the outline generation phase, passes it to image generation prompts with explicit text embedding instructions, and validates that generated images contain readable Chinese text. Handles character encoding (UTF-8), font selection, and text layout to ensure accurate Chinese text rendering without post-generation OCR or manual text addition.

Exposes Flask REST API endpoints for the two-phase generation workflow: POST /api/generate/outline (topic → outline), POST /api/generate/images (outline → images), and GET /api/generate/status (progress polling). Each endpoint accepts JSON request bodies with generation parameters (topic, reference images, provider config), validates inputs, and returns JSON responses with generated content or error details. Implements request validation, error handling, and optional authentication/rate limiting for production deployments.

Accepts optional user-uploaded reference images and incorporates them into both outline generation and image generation pipelines via multimodal LLM APIs. The system encodes reference images as base64 or file uploads, passes them to text and image generation models that support vision capabilities, and uses them to influence content style, tone, and visual direction without explicit fine-tuning. Handles image validation, format conversion, and size constraints before submission to downstream providers.

Streams generation progress updates to the frontend in real-time using HTTP Server-Sent Events (SSE), allowing users to monitor outline generation and image generation phases without polling. The backend emits progress events at key checkpoints (outline started, outline completed, image 1 generated, image 2 generated, etc.), and the frontend Vue.js application listens to these events and updates the UI reactively. Enables long-running operations (30+ seconds) to feel responsive and transparent to users.

Implements a configuration-driven provider selection system where text and image generation providers are specified in YAML/JSON configuration files (provider_config.yaml) rather than hardcoded in application logic. At runtime, the system instantiates the appropriate text/image generator client based on configuration, enabling users to swap providers (Google GenAI → OpenAI → Ollama) without code changes or redeployment. Configuration includes API endpoints, model names, authentication credentials, and provider-specific parameters (temperature, max_tokens, image resolution).

Automatically compresses and optimizes generated images post-generation to meet Xiaohongshu platform constraints (file size, aspect ratio, resolution). The system applies lossy/lossless compression algorithms, generates thumbnail variants, and validates output dimensions and file sizes before returning to user. Compression parameters are tunable via configuration to balance quality vs. file size based on platform requirements.

Implements exponential backoff retry logic for transient API failures (rate limits, timeouts, temporary outages) across text and image generation providers. The system catches provider-specific exceptions, logs errors with context, and automatically retries failed requests with increasing delays (1s, 2s, 4s, 8s, etc.) up to a configurable maximum. Distinguishes between retryable errors (429 rate limit, 503 service unavailable) and fatal errors (401 auth failure, 400 bad request) to avoid wasting retries on unrecoverable failures.

Provides a Vue.js single-page application (SPA) frontend with Pinia state management that orchestrates the two-phase content generation workflow (outline → image generation). The frontend includes HomeView for topic input and reference image upload, SettingsView for provider configuration, and reactive UI components that display generation progress via SSE streaming. Pinia stores manage application state (generation status, generated images, provider settings) and enable cross-component communication without prop drilling.

Packages the entire RedInk application (Flask backend + Vue.js frontend) into Docker containers with docker-compose orchestration for easy deployment and scaling. The docker-compose.yml file defines services for the backend (Python Flask), frontend (Node.js build + Nginx reverse proxy), and optional services (Redis for caching, PostgreSQL for persistence). Enables one-command deployment ('docker-compose up') without manual dependency installation or configuration, with environment variables for provider credentials and configuration.

Supports high-concurrency image generation by allowing multiple image generation requests to be submitted in parallel to the backend, with configurable concurrency limits and request queuing. The system uses async/await patterns (Python asyncio or thread pools) to manage concurrent API calls to image generation providers, with per-provider rate limit handling to avoid exceeding API quotas. Enables batch generation of multiple posts (e.g., 10 posts × 6-9 images = 60-90 images) without sequential bottlenecks.