One Python Script Handles CSV Metadata for Adobe, Vecteezy, and Dreamstime

Meta Description

A standard-library Python script generates the exact CSV metadata required by Adobe Stock, Vecteezy, and Dreamstime from the same asset folder, solving header mismatches and duplicate uploads while running on a 2GB low-spec server.

Article Content

When batch-uploading assets to Adobe Stock, Vecteezy, and Dreamstime, the biggest headache isn't image quality—it's the CSV header that never quite lines up. One developer shared his solution: a set of pure standard-library Python scripts that generate the required CSVs for all three platforms from the same asset folder, while completely solving the duplicate upload problem.

Three Platforms, Three Headers, One Root Problem

Adobe Stock requires five columns, Vecteezy requires four, and Dreamstime requires fifteen. Same assets, same titles, same keywords—yet you have to fill out three completely different table structures. The result of manually maintaining three spreadsheets: sooner or later you'll upload the wrong file to the wrong platform, and the rejection is instant and silent—the file simply never appears in your portfolio.

The author's make_metadata.py takes one input: the asset folder, and outputs the exact header each platform requires—no extra columns, no missing ones. Usage is via the --platform flag to specify the target platform:

python make_metadata.py ./my-assets --platform adobe --out metadata.csv
python make_metadata.py ./my-assets --platform vecteezy --out vecteezy.csv
python make_metadata.py ./my-assets --platform dreamstime --out dreamstime.csv

The script only depends on the Python standard library—no pip install, no third-party dependencies. This matters more than it sounds—when your pipeline runs on a 1 vCPU, 2 GB RAM server with no GPU, every dependency is a potential point of failure.

Titles and Keywords: Honest Defaults vs. Real Submission Standards

Without additional input, the script converts filenames to title case and uses them as titles. This is good enough for getting the pipeline running the first time, but the author explicitly emphasizes: this is not suitable for actual submission. Reviewers on all three platforms can spot a filename-as-title from a mile away.

By passing --titles titles.json, the script reads real titles and keywords for each file. The author recommends placing this JSON file next to the asset folder and filling it out before submission. The defaults exist so the pipeline doesn't block on missing data, but replacing the defaults is the user's responsibility, not the script's.

Stock platform search rankings depend heavily on semantic matching between titles and keywords. Adobe Stock recommends keeping titles under 70 characters, with a keyword limit of 49, and requires them ordered from most to least relevant—the platform algorithm gives higher weight to the first 10 keywords. Vecteezy and Dreamstime have different field constraints, and Dreamstime's 15-column structure also includes category numbers and model release metadata. If the title is just a filename like IMG_2043.jpg converted to Img 2043, neither reviewers nor buyers can extract any semantic information from it. Even if the asset passes review, it will have virtually zero exposure in search results due to missing keywords. Therefore, titles.json is not optional—it's the key input that determines whether your assets can be found.

The Most Overlooked Yet Most Consequential Problem: Duplicate Uploads

The author shared an expensive lesson: he re-ran a partially completed batch job, causing multiple assets to be uploaded twice. Duplicate submissions are the fastest way to get noticed by the review team, and once flagged, every subsequent batch faces slower review.

The solution is a roughly forty-line ledger tool called upload_tracker.py, also using only the standard library:

python upload_tracker.py pending items.txt   # items not yet completed
python upload_tracker.py done "asset-001.jpg"
python upload_tracker.py status

Before any batch run, it checks the ledger first. On re-runs, completed items are automatically skipped. The author says that since using this ledger, he hasn't had a single duplicate upload. If you take away only one tool from this article, it should be this ledger script.

The penalty logic for duplicate submissions on stock platforms deserves elaboration. Platforms like Adobe Stock and Vecteezy allocate review queue priority based on account reputation. Duplicate uploads are flagged by the system as "low-quality account behavior," causing all subsequent submissions from that account to enter a slower manual review channel—review cycles can stretch from hours to days or even weeks. More seriously, some platforms directly freeze upload permissions for accounts that hit cumulative duplicate thresholds. The core value of the ledger tool is introducing "idempotency" into the batch process: by querying local status records before submission and writing back results after, the entire pipeline can be safely interrupted and re-run without relying on human memory to track which assets have been processed. This is also a fundamental design principle of all reliable data pipelines.

Running the Full Pipeline on a 2 GB Server

The entire pipeline—including these scripts—runs on a single-core vCPU, 2 GB RAM, no-GPU environment. Several habits make this feasible: run only one process at a time—parallel image processing on a single-core machine only leads to resource contention; call gc.collect() after each asset to free memory; measure peak memory with resource.getrusage(RUSAGE_SELF).ru_maxrss rather than average usage, because peak is what causes processes to be killed; for heavyweight rendering steps, run each file in a separate subprocess to ensure memory is truly returned to the OS; render at needed resolution—checking previews at 60 dpi instead of 300 dpi saves significant memory.

The metadata and tracking scripts are pure text processing and run effortlessly in this environment. What really needs memory discipline are the image-related scripts, such as the cover renderer in pack_product.py.

resource.getrusage(RUSAGE_SELF).ru_maxrss is a system call wrapper provided by Python's resource module. The ru_maxrss field returns the peak resident set size (RSS) since process startup, in KB on Linux and bytes on macOS. The reason to monitor peak rather than average is that the OS OOM Killer checks whether the instantaneous peak touches the memory limit when deciding whether to terminate a process. On a 2 GB machine, a script that uses only 200 MB on average but spikes to 2.1 GB at peak will still be killed—and looking only at the average completely masks this risk. In practice, call it once before and after key steps and take the maximum, or wrap it in a decorator that prints on function exit, so you can pinpoint exactly which step is consuming the memory.

Packaging Is Where the Sale Actually Happens

A zip with a real cover sells; a bare file doesn't. The author found through comparison: in the same week, at the same price, a product with a 1280×720 cover outsold an identical product without one.

pack_product.py takes a folder, title, subtitle, and file count, and outputs three things: the product zip, a 1280×720 cover, and a 600×600 thumbnail. It uses Pillow for image processing—one of only two third-party packages in the entire toolkit. The other is reportlab, used by md2pdf.py to convert Markdown files into styled PDFs with headings, tables, lists, and links. One command per product:

python md2pdf.py content.md product.pdf "My Product Title"
python pack_product.py my-product "My Product" "A short subtitle" 9

Output goes to the _system folder by default, redirectable via the --dir parameter or the PACK_ROOT environment variable without modifying scripts.

Folder Structure That Keeps Your Product Library from Becoming a Junk Drawer

The entire toolkit assumes the following directory structure:

project/
  assets/            raw output
  output/            submittable files + metadata.csv
  packs/             finished zips + covers
  research/          notes and sources
  scripts/           utility scripts

The author particularly emphasizes: never delete the research/ folder. Notes and logs are raw material for future products. Deleting them for "cleanup" is a mistake the author made once and won't repeat.

The Real Production Context Behind This Toolkit

These four scripts are the packaging layer of a larger pipeline. That pipeline produced 39 finished products, 856 MB of output, from roughly 19,000 lines of code and 300+ pages of research—all running on the same 1 vCPU, 2 GB RAM machine. The author didn't design the scripts first and hope they'd work—he encountered failures first: rejected CSV headers, duplicate submissions, bare files that wouldn't sell, then wrote the minimal fix tool for each problem.

One-line Summary

A set of pure standard-library Python scripts that generate three-platform CSVs from one asset folder and eliminate duplicate uploads.

Paragraph Summary

The article introduces a toolkit of four Python scripts written by a developer for batch stock asset uploads. The core pain point is that Adobe Stock, Vecteezy, and Dreamstime require completely different CSV header structures, and manually maintaining multiple spreadsheets easily leads to silent upload failures. The author implemented make_metadata.py with pure standard library to generate correct headers per platform from the same asset folder, and emphasizes that titles and keywords must be provided as real content via titles.json—the default filename conversion is only for getting the pipeline running. The roughly forty-line upload_tracker.py ledger tool solves the duplicate submission problem the author personally experienced, preventing accounts from being flagged by review teams. The entire pipeline runs on a 1 vCPU, 2 GB RAM, no-GPU server, relying on serial processing, gc.collect(), peak RSS monitoring, and on-demand resolution rendering to control memory. The packaging step uses pack_product.py to generate product zips with 1280×720 covers, which empirically outsell bare files.