{ "id": 581213, "title": "10th Place Solution: Flux 1 Dev -> SVG optimization -> Postprocessing", "content": "

10th Place Solution: Drawing with LLMs

\n

Team: BERA

\n

We’re thrilled to have placed 10th in the \"Drawing with LLMs\" competition. Thanks to the organizers and metric team for continuously iterating and improving the challenge and other participants for sharing great work.

\n

Our solution focuses on generating high-quality images first, and then converting and optimizing them into compact, accurate SVGs under the tight 10KB constraint. Our pipeline emphasizes image quality, conversion fidelity, and smart selection via the competition's evaluators, the efficiency of the SVG conversion being particularly strong.

\n

Pipeline Components

\n

Image (Flux-1-Dev + HyperSD + Nunchaku) + SVG (vtracer + svgo + custom geometry simplification + OCR addition) + Selection (VQA + Aesthetic + OCR) + Optional Border Addition

\n

Overview of Our Pipeline

\n
    \n

  1. Image Generation (Flux 1 Dev + HyperSD + Nunchaku)

    \n
    2. \n

  2. Image → SVG Conversion (vtracer + Path Simplification)

    \n\n
    \n

    e.g., If point B lies within 2 pixels of line A–C, we drop B.

    \n
    3. \n
\n\n
    \n

  1. Candidate Selection (VQA + Aesthetic Score + OCR Robustness)

    \n
    2. \n
\n

\"Example

\n

Debugging + Engineering Pain Points

\n

We spent dozens of hours debugging edge cases, and the new submission format introduced several non-trivial issues:

\n\n

Notes on Generation Behavior

\n\n

Alternative Submission (Not Selected)

\n

We had another submission that scored much higher on private LB, but slightly worse on public, so we sadly didn't select it, but maybe it's still interesting for you to hear of these additional improvements:

\n\n

Final Thoughts

\n

We learned a lot about image generation pipelines and SVG compression. The challenge pushed us to get creative with pipelines, build interpretable evaluators, and respect tight compute budgets.

\n

Thanks again to the hosts and congrats to all participan

", "comments": [ { "id": 3212077, "author_name": "Mikhail Golubchik", "author_url": "", "post_date": "2025-05-29T09:20:49.010000", "content": "

Solid work. Elegant solutions, especially in \"Image → SVG Conversion\".

\n

The \"abstract\" category was also really tough for me. There’s definitely potential in using LLMs to help generate those kinds of difficult abstract descriptions. Technically, I managed to mix approaches and even pack it into a working submission — and the geometric images did get higher scores and were selected. But overall, the approach didn’t quite outperform pure SD-based generation for me on the leaderboard.

", "votes": 1, "replies": [ { "id": 3215398, "author_name": "Raki", "author_url": "", "post_date": "2025-06-02T06:56:19.867000", "content": "

Yeah we also ran a hybrid switching between Janus Pro and Flux (Janus Pro being better at abstract). But the additional compute and VRAM requirements gave us a better return when used them for our selection pipeline.

", "votes": 1, "replies": [] } ] } ], "comment_count": 2, "messages": [ { "id": 3212000, "postDate": "2025-05-29T06:41:16.353Z", "content": "

10th Place Solution: Drawing with LLMs

\n

Team: BERA

\n

We’re thrilled to have placed 10th in the \"Drawing with LLMs\" competition. Thanks to the organizers and metric team for continuously iterating and improving the challenge and other participants for sharing great work.

\n

Our solution focuses on generating high-quality images first, and then converting and optimizing them into compact, accurate SVGs under the tight 10KB constraint. Our pipeline emphasizes image quality, conversion fidelity, and smart selection via the competition's evaluators, the efficiency of the SVG conversion being particularly strong.

\n

Pipeline Components

\n

Image (Flux-1-Dev + HyperSD + Nunchaku) + SVG (vtracer + svgo + custom geometry simplification + OCR addition) + Selection (VQA + Aesthetic + OCR) + Optional Border Addition

\n

Overview of Our Pipeline

\n
    \n

  1. Image Generation (Flux 1 Dev + HyperSD + Nunchaku)

    \n
    2. \n

  2. Image → SVG Conversion (vtracer + Path Simplification)

    \n\n
    \n

    e.g., If point B lies within 2 pixels of line A–C, we drop B.

    \n
    3. \n
\n\n
    \n

  1. Candidate Selection (VQA + Aesthetic Score + OCR Robustness)

    \n
    2. \n
\n

\"Example

\n

Debugging + Engineering Pain Points

\n

We spent dozens of hours debugging edge cases, and the new submission format introduced several non-trivial issues:

\n\n

Notes on Generation Behavior

\n\n

Alternative Submission (Not Selected)

\n

We had another submission that scored much higher on private LB, but slightly worse on public, so we sadly didn't select it, but maybe it's still interesting for you to hear of these additional improvements:

\n\n

Final Thoughts

\n

We learned a lot about image generation pipelines and SVG compression. The challenge pushed us to get creative with pipelines, build interpretable evaluators, and respect tight compute budgets.

\n

Thanks again to the hosts and congrats to all participan

", "rawMarkdown": "# 10th Place Solution: Drawing with LLMs\n\n**Team:** BERA\n\nWe’re thrilled to have placed 10th in the \"Drawing with LLMs\" competition. Thanks to the organizers and metric team for continuously iterating and improving the challenge and other participants for sharing great work. \n\nOur solution focuses on **generating high-quality images first**, and then **converting and optimizing them into compact, accurate SVGs** under the tight 10KB constraint. Our pipeline emphasizes image quality, conversion fidelity, and smart selection via the competition's evaluators, the efficiency of the SVG conversion being particularly strong.\n\n## Pipeline Components\nImage (Flux-1-Dev + HyperSD + Nunchaku) + SVG (vtracer + svgo + custom geometry simplification + OCR addition) + Selection (VQA + Aesthetic + OCR) + Optional Border Addition\n\n## Overview of Our Pipeline\n\n1. **Image Generation (Flux 1 Dev + HyperSD + Nunchaku)**\n\n * We used **Flux 1 Dev**, enhanced with **HyperSD LoRA** to reduce inference to **8 steps** from default **50 steps** and **Nunchaku** for loading the transformer part in a much faster version. We quantized all components of the pipeline in **4bit** with BitsAndBytes so that they fit on a **single T4**.\n * Initially, we couldn't get parallel generation to run, but switching to the newest Nunchaku dev version resolved the issue.\n * Final throughput: \\~10 images in \\~20 seconds using a single T4.\n\n2. **Image → SVG Conversion (vtracer + Path Simplification)**\n\n * Each image was converted using **vtracer**, which gave us clean, layered SVGs.\n * We applied **geometric simplification** by trimming intermediate points that added negligible curvature:\n > e.g., If point B lies within 2 pixels of line A–C, we drop B.\n* Compression with **SVGO** followed. We performed **binary search over vtracer parameters** to find the best configuration that used under 10000 bytes.![\n](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3747152%2Feb3029c2bf9639f6c4f9e6de666203dd%2FSVG%20compare.png?generation=1748500604684319&alt=media)\n\n* This step was expensive and ran **multiprocessed on 4 threads**.\n* We also added **two small “M” watermark** in black and white to mitigate OCR false positives.\n\n\n3. **Candidate Selection (VQA + Aesthetic Score + OCR Robustness)**\n\n * SVGs were scored using the **VQA and Aesthetic evaluators**.\n * We ranked all candidates, then searched *backwards* to find the first image that **passed OCR checks** (a major pain point).\n * On the top candidate, we created **two variants**: one original, and one with a **gradient silver border**. We used the best-scoring one.\n\n![Example Output with Gradient Silver Border](https://www.googleapis.com/download/storage/v1/b/kaggle-forum-message-attachments/o/inbox%2F3747152%2F1dd4964d416672dccf865060104ebf21%2FOutput%20final.png?generation=1748501085716653&alt=media)\n\n## Debugging + Engineering Pain Points\n\nWe spent **dozens of hours debugging edge cases**, and the new submission format introduced several non-trivial issues:\n\n* **SVGO**: Wrapped with a custom Python interface and loaded it into a private GitHub repo, then installed it in the dependency manager with PAT (personal acess token). \n\n* **Nunchaku**: Didn’t work via standard install—had to fork and install via GitHub and then still load in the binary manually.\n\n* **Multiprocessing and Execution Graph Dependencies**: Ensuring image generation on cuda:0, SVG conversion and cuda:1 image selection stages didn’t block each other would have been a huge speed improvement but we could not get it to run on the submission server, though it ran in notebooks, on save and even on importing the package. \n\n## Notes on Generation Behavior\n\n* **Landscapes**: Near-perfect every time. The best modality for our pipeline.\n* **Fashion**: Challenging—details often lost in SVG conversion due to subtle features.\n* **Geometry**: Almost hopeless. Across 12+ models, even basic shapes like trapezoids only succeeded \\~10% of the time.\n\n## Alternative Submission (Not Selected)\n\nWe had another submission that scored much higher on **private LB**, but slightly worse on **public**, so we sadly didn't select it, but maybe it's still interesting for you to hear of these additional improvements:\n\n* It involved **prompt rewriting**, passing different forms to different encoders.\n* Initially failed because we sent the **same format** to both:\n\n * CLIP prefers **comma-separated keywords**.\n * T5 prefers **natural sentences**.\n* Once separated, prompt rewriting improved performance in niche cases (e.g., animals and food).\n\n## Final Thoughts\n\nWe learned a lot about image generation pipelines and SVG compression. The challenge pushed us to get creative with pipelines, build interpretable evaluators, and respect tight compute budgets.\n\nThanks again to the hosts and congrats to all participan", "votes": 14 }, { "id": 3212077, "postDate": "2025-05-29T09:20:49.010Z", "content": "

Solid work. Elegant solutions, especially in \"Image → SVG Conversion\".

\n

The \"abstract\" category was also really tough for me. There’s definitely potential in using LLMs to help generate those kinds of difficult abstract descriptions. Technically, I managed to mix approaches and even pack it into a working submission — and the geometric images did get higher scores and were selected. But overall, the approach didn’t quite outperform pure SD-based generation for me on the leaderboard.

", "rawMarkdown": "Solid work. Elegant solutions, especially in \"Image → SVG Conversion\".\n\nThe \"abstract\" category was also really tough for me. There’s definitely potential in using LLMs to help generate those kinds of difficult abstract descriptions. Technically, I managed to mix approaches and even pack it into a working submission — and the geometric images did get higher scores and were selected. But overall, the approach didn’t quite outperform pure SD-based generation for me on the leaderboard.", "votes": 1, "replies": [ { "id": 3215398, "postDate": "2025-06-02T06:56:19.867Z", "content": "

Yeah we also ran a hybrid switching between Janus Pro and Flux (Janus Pro being better at abstract). But the additional compute and VRAM requirements gave us a better return when used them for our selection pipeline.

", "rawMarkdown": "Yeah we also ran a hybrid switching between Janus Pro and Flux (Janus Pro being better at abstract). But the additional compute and VRAM requirements gave us a better return when used them for our selection pipeline. ", "votes": 1 } ] } ], "complete": true, "source": "live", "fetched_at": "2026-10-20T09:10:45Z", "competition_id": 89659, "competition_slug": "drawing-with-llms", "team_id": 13404656, "solution_url": "/competitions/drawing-with-llms/writeups/bera-10th-place-solution-flux-1-dev-svg-optimizati" }