Coder Legion - Recent posts tagged image-processing

Validate AI Video Reference Images with Python Before Generation

Mon, 26 Oct 2026 10:47:37 +0000

A reference image can look perfectly fine in a browser and still cause problems in an AI video workflow.

Perhaps a character portrait was accidentally exported at 320 × 320 pixels. Two reference files might contain exactly the same image under different filenames. Or a damaged image might still exist in the project folder even though it can no longer be opened properly.

These are problems we can catch before sending anything to a video generation tool.

In this tutorial, we'll build a small Python validator that checks image formats, dimensions, aspect ratios, file integrity, and duplicate content.

We'll also generate test images to verify that the script actually works.

The solution uses Pillow and Python's standard library. No API key or AI video service is required.

1. Why Validate Reference Images?

Reference-guided video generation often involves several assets:

Character portraits
Product photographs
Background images
Visual style references
Storyboard frames

As a project grows, these files may be renamed, resized, replaced, or duplicated.

A basic validation step can catch some of these mistakes before generation begins.

For this example, our validator will check five things:

Whether the image uses a supported format.
Whether it can be opened and decoded.
Whether its dimensions meet a configurable minimum.
Whether its aspect ratio matches an optional requirement.
Whether another file has identical contents.

These checks do not guarantee better AI video output. They simply help ensure the input files meet a known set of requirements.

2. Set Up the Project

Install Pillow:

python -m pip install Pillow

Create the following project structure:

video-project/
├── references/
├── check_references.py
└── make_test_images.py

We'll first create the validator, then generate several images to test it.

3. Build the Image Validator

Create check_references.py:

import argparse
import hashlib
import json
import warnings
from pathlib import Path

from PIL import Image, UnidentifiedImageError

ALLOWED = {
    ".png": "PNG",
    ".jpg": "JPEG",
    ".jpeg": "JPEG",
    ".webp": "WEBP",
}


def fingerprint(path):
    h = hashlib.sha256()

    with path.open("rb") as fh:
        for chunk in iter(
            lambda: fh.read(1024 * 1024), b""
        ):
            h.update(chunk)

    return h.hexdigest()


def inspect(path, minimum, ratio):
    errors = []

    try:
        expected = ALLOWED.get(
            path.suffix.lower()
        )

        if expected is None:
            return {
                "file": path.name,
                "errors": ["Unsupported extension"],
            }

        # Check file structure and decode image data.
        with warnings.catch_warnings():
            warnings.simplefilter(
                "error",
                Image.DecompressionBombWarning
            )

            with Image.open(path) as image:
                actual = image.format
                width, height = image.size
                image.verify()

            # Reopen after verify() for decoding.
            with Image.open(path) as image:
                image.load()

        if actual != expected:
            errors.append(
                f"Extension/format mismatch: {actual}"
            )

        if min(width, height) < minimum:
            errors.append(
                f"Too small: {width}x{height}"
            )

        if ratio is not None:
            actual_ratio = width / height

            if abs(actual_ratio - ratio) > 0.03:
                errors.append(
                    f"Unexpected ratio: {actual_ratio:.3f}"
                )

        return {
            "file": path.name,
            "size": [width, height],
            "sha256": fingerprint(path),
            "errors": errors,
        }

    except (
        OSError,
        ValueError,
        UnidentifiedImageError,
        Image.DecompressionBombError,
        Image.DecompressionBombWarning,
    ) as exc:
        return {
            "file": path.name,
            "errors": [f"Unreadable image: {exc}"],
        }


def main():
    parser = argparse.ArgumentParser()

    parser.add_argument(
        "directory",
        type=Path
    )

    parser.add_argument(
        "--min-side",
        type=int,
        default=512
    )

    parser.add_argument(
        "--ratio",
        type=float
    )

    args = parser.parse_args()

    if (
        args.min_side < 1
        or (
            args.ratio is not None
            and args.ratio <= 0
        )
    ):
        parser.error("Invalid size or ratio")

    if not args.directory.is_dir():
        parser.error("Directory not found")

    paths = sorted(
        path
        for path in args.directory.iterdir()
        if path.is_file()
    )

    if not paths:
        parser.error("Directory is empty")

    seen = {}
    results = []

    for path in paths:
        item = inspect(
            path,
            args.min_side,
            args.ratio
        )

        digest = item.get("sha256")

        if digest:
            if digest in seen:
                item["errors"].append(
                    f"Byte-identical to {seen[digest]}"
                )
            else:
                seen[digest] = path.name

        results.append(item)

    print(json.dumps(results, indent=2))

    return (
        1 if any(item["errors"] for item in results)
        else 0
    )


if __name__ == "__main__":
    raise SystemExit(main())

The script processes each file in the selected directory and generates a JSON report.

It returns exit code 0 when every file passes, or 1 when one or more files fail.

That makes it usable in local scripts and automated pipelines.

4. Generate Test Images

We should not assume the validator works just because the code runs.

Let's create files that exercise its main checks.

Create make_test_images.py:

from pathlib import Path
from shutil import copyfile

from PIL import Image

folder = Path("references")
folder.mkdir(exist_ok=True)

# A valid image.
Image.new(
    "RGB",
    (1024, 1024),
    "white"
).save(folder / "valid.png")

# An undersized image.
Image.new(
    "RGB",
    (320, 320),
    "red"
).save(folder / "small.png")

# A byte-identical duplicate.
copyfile(
    folder / "valid.png",
    folder / "valid_copy.png"
)

# A deliberately invalid image file.
(folder / "broken.png").write_bytes(
    b"not a real image"
)

Run:

python make_test_images.py

Your references directory should now contain four files:

references/
├── valid.png
├── valid_copy.png
├── small.png
└── broken.png

These test assets allow us to check several error conditions without downloading external images.

5. Run the Validator

Execute:

python check_references.py references

The validator should identify:

File	Expected result
`valid.png`	Valid size and format
`valid_copy.png`	Exact duplicate detected
`small.png`	Too small: 320x320
`broken.png`	Unreadable image

The duplicate may be reported against either filename, depending on the order in which the files are processed.

What happens when everything is valid?

Remove the broken, small, and duplicate files, leaving only valid.png.

Run the validator again:

python check_references.py references

The result should contain an empty errors list:

{
  "file": "valid.png",
  "size": [1024, 1024],
  "sha256": "...",
  "errors": []
}

The SHA-256 value is abbreviated here for readability. The actual script prints the complete hash.

The process should also exit successfully.

Test a custom minimum size

You can change the minimum dimensions:

python check_references.py references --min-side 768

This requires both dimensions to be at least 768 pixels.

It is a project-level rule, not a universal requirement imposed by AI video models.

A character portrait and a wide landscape background may need different dimension policies.

Test an aspect ratio

For a project expecting roughly 16:9 images:

python check_references.py references --ratio 1.777778

The script allows a difference of 0.03 between the actual and requested width-to-height ratios.

This is useful for a consistent background-image set, but shouldn't automatically be applied to every reference image.

Portraits, objects, and backgrounds often need different framing.

6. Why Use SHA-256 for Duplicate Detection?

The validator calculates a SHA-256 fingerprint for every successfully inspected image.

If two files have identical bytes, their hashes match.

This catches a common asset-management mistake: copying an image under another filename and accidentally including both files in a reference set.

However, SHA-256 is not a visual similarity detector.

For example:

Two identical files with different names will be detected.
A JPEG recompressed with different settings will usually produce a different hash.
An image with modified metadata may have a different hash.
Two images showing the same subject at different resolutions will generally not match.

For visual similarity detection, teams would need a separate method such as perceptual hashing.

The choice depends on the problem being solved.

If the goal is to find exact duplicate files, SHA-256 is simple and reliable.

7. Use Validation Before AI Video Generation

Reference-heavy video projects often use separate images to guide characters, environments, objects, and camera composition.

Platforms such as Kling 4.0 describe reference-guided generation and multi-keyframe controls, making reference preparation a relevant part of the workflow.

The validator operates entirely on local files. It does not connect to Kling 4.0 or require a provider-specific API.

It can detect invalid or duplicate files before upload, while actual reference limits, accepted formats, and model requirements must be confirmed through the selected service.

A practical workflow might be:

Collect reference images in a project directory.
Validate file formats and dimensions.
Identify duplicates and corrupted files.
Review asset permissions.
Upload only the approved references.
Review the generated video for visual accuracy.

Local validation reduces avoidable input problems, but it does not guarantee that a generated character or object will remain consistent.

8. Production Considerations

This validator is deliberately small.

For a production asset pipeline, several additions may be useful.

EXIF orientation

Some photographs include orientation metadata that changes how they are displayed. The script checks stored image dimensions rather than applying EXIF-based rotation.

File-size and pixel limits

Large or malicious image files can consume significant memory during decoding. Production systems handling untrusted files should enforce resource limits and use isolated processing environments.

Different reference roles

A character portrait, product image, and background scene should not necessarily share the same minimum dimensions or aspect-ratio rules.

Asset permissions

A technically valid reference is not automatically authorized for upload.

Teams should confirm that they have permission to use customer photographs, internal screenshots, copyrighted artwork, and images of recognizable people.

Removing private information does not necessarily make confidential business assets eligible for external processing.

These issues matter just as much as file dimensions when a tool becomes part of a real production workflow.

Conclusion

AI video generation involves creative uncertainty, but basic reference-file validation is predictable.

Before using generation credits, a team can check whether its images are readable, large enough for the intended purpose, correctly formatted, and free of exact duplicates.

The process does not guarantee better motion, perfect character continuity, or accurate generated details.

It simply removes a few preventable mistakes before the creative work begins.

For teams handling many reference files, that's a useful place to introduce a small amount of automation.

Our AI staging model sometimes moves the camera. Here is how to spot it, and how we catch it

Sat, 24 Oct 2026 23:14:24 +0000

A virtual staging render is supposed to be the same photo with different furniture. Same walls, same windows, same door, and the same spot where the photographer stood. Most of the time the image model gives exactly that. Sometimes it does not.

We run an AI virtual staging tool, and one of the quieter failures we deal with is this one: the model moves the camera.

What it looks like

It is rarely dramatic. On its own the render looks great. The sofa is nice, the light is warm, nothing is melted or floating. Only when you put it next to the original do you notice that the room is being seen from a different place.

The versions we see most often:

A step back. A wardrobe that the photo cut off at the edge turns into a wall, and the view moves back behind it. Suddenly there is more room than the photographer ever captured.
Straightened up. A bedroom shot from the corner comes back facing the bed square on, like a catalogue page.
Zoomed in. The frame creeps toward the fireplace or the archway.

For a listing photo this matters. The picture is supposed to show the room a buyer will walk into. Some MLS rules go further and require an unstaged photo of the same view alongside the staged one. If the staged version was taken from somewhere else, the pair does not match, and anyone comparing them will see it.

How to spot it by eye

You do not need software for the obvious cases. Put the original and the render side by side and ignore the furniture. Look at the things furniture cannot change:

The line where the ceiling meets the walls. It should sit in the same place in both images. If it is higher, lower or tilted differently, the camera moved.
Window and door edges. Check how far each one is from the edge of the frame. If a door that touched the left edge now has a strip of wall beside it, the view shifted.
Whatever is cut off. Anything the original cropped at the frame edge should be cropped at the same place.

If all three line up, the camera almost certainly stayed put, whatever happened to the sofa.

Why we could not just ask an AI

Our first idea was the obvious one. We already use a vision model to compare every render with its original and answer a fixed list of yes-or-no questions: is the window still there, is the door still a door, and so on. So we added one more question: is this the same viewpoint?

It did not work. Renders shot from a visibly different spot kept passing, across three separate rounds of cases we had checked by hand. We tried laying the two images over each other at half strength and asking whether the walls looked doubled. Not reliable either. A stronger model later had the opposite habit and called good renders moved. Today its answers about the camera do not count for room photos at all.

What we built instead

So we measure it, much the way you would by eye, with two plain checks.

The first one traces the line where the walls meet the ceiling across the whole width of the photo and compares the two lines. Furniture rarely reaches the ceiling, so that line should not change. Its weak spot is decoration: a dark beam or a picture hung high can pull the traced line off course.

The second one estimates how far away the back wall is, column by column, in the upper part of the image, and compares the two results. Its weak spot is glass. Windows and mirrors are read differently every time.

The useful part is that the two weak spots rarely meet. A picture on the wall does not change depth, and glass does not move the ceiling line. So a render is flagged only when both checks agree that the camera moved. On our hand-labelled set of 24 pairs, that caught all 5 moved renders with no false alarms. The margin was thin, so borderline scores are only logged and never fail a render.

A flagged render is rejected the same way as one with a missing door, and the pipeline makes another attempt. If the check itself breaks or runs slow, the render is judged by the other checks instead of being held up.

What it still gets wrong

Three things, and we would rather name them than hide them.

Decoration and glass in the same room. A towel rail next to a glass shower. A picture shelf beside a full-height window. Both checks get fooled a little at the same time, and a render is flagged even though the camera held still.

A turn under a flat ceiling. If the camera only turns and the ceiling is flat, the ceiling line barely changes, the first check stays quiet, and the render slips through. A bedroom straightened to face the bed is the usual case.

A straight step back. This one showed up in October on close-up, cluttered photos. Both checks look at where things sit across the frame, not at how big they look, so a pure pull-back hardly registers. On 20 hard photos the check caught 2 of 5 bad frames and missed 3, all of them pull-backs. A simple scale comparison caught 2 of those 3, but it also raised false alarms of its own, so it is not live yet.

What we took from it

A model that describes a room well is not the same as a model that can tell where the camera stood. For that one question, two boring measurements did better. They are not perfect, but they fail in ways we can name and test.

If you are checking a staged photo yourself, the same habit works: skip the furniture and look at the ceiling line, the window edges and what is cut off at the frame. If you are buying, you can ask for the unedited original of every staged photo. And if you are the one taking the picture, remember that close-up, cluttered shots are where the step-back problem showed up, so shoot the room wide and level.

The full technical write-up, with the six approaches we tried, the calibration numbers and the bugs we hit in production, is on dev.to.

We build this at AI Flip Room.

Validate Image Enlargement at the Size Users Will Actually See

Fri, 23 Oct 2026 16:37:50 +0000

Disclosure: I work on upscaleimg.org. These are practical quality checks, not measured performance claims about the service.

An enlarged image can look impressive in a small preview and still fail when placed on a product page. More pixels are not the same thing as more reliable detail. A useful review checks both the output file and its intended display context.

Calculate the required dimensions first

For a web image, start from the largest rendered width and the display density you want to support. A 600 CSS-pixel slot at 2x density calls for roughly 1200 image pixels across. That is a delivery target, not a guarantee of perceived sharpness.

Choose an upscale image workflow only after identifying the source dimensions and crop. Upscaling a wide photo does not solve the problem of needing a portrait composition.

Use paired comparisons

Keep the original and enlarged file. Compare them at the same display size, then inspect output pixels around text, faces, thin lines, and repeated patterns. Look for halos, invented texture, altered letters, and softened edges.

Do not compare a zoomed original with a fit-to-window output and call the difference an accuracy improvement. Record the viewing scale and note which details changed.

Check delivery separately

Record output width, height, format, byte size, and the intended slot. Generate appropriately sized delivery variants after approval rather than serving the largest download everywhere. Preserve the approved master so later compression changes can be reviewed independently.

Upscale Image provides browser-based enlargement and enhancement. The final review is still important when the image contains factual details such as product labels or diagrams. AI-created detail should not be treated as recovered evidence.

For print, calculate pixels per inch using the final crop and physical size, then inspect a proof when practical. A resolution calculation alone cannot certify print quality.

Website: https://upscaleimg.org/

Should a Resized Image Export Need a Fresh Visual Review?

Fri, 23 Oct 2026 13:03:59 +0000

Cover: an original AI-generated illustration of a hypothetical review/export workflow, not an actual product result.

A reviewer approves revision R-2 of an AI-edited property photo. The export step then creates a smaller JPEG for delivery.

Where should the review boundary sit?

Allow predetermined resizing/compression after approval, with a separate export record.
Require a final visual check of every delivered file.
Use both, with a stricter check when the transform changes the crop, label or visible content.

The distinction I would test is whether the derivative merely changes encoding or changes what the client sees. Even a routine export can make a disclosure label unreadable.

A file digest can identify the exact exported bytes, but it does not establish visual correctness. MDN explains the narrow role of a digest here: https://developer.mozilla.org/en-US/docs/Web/API/SubtleCrypto/digest

What rule has worked in your image or document pipeline, and which edge case made you change it?

Context: I work on EstateAI content and SEO. This is a hypothetical workflow question, not a claim about its current implementation.

A Regression Checklist for Prompt-Based Image Editing

Fri, 23 Oct 2026 11:10:20 +0000

Disclosure: I work on nanobanana-ai.org. The checklist below is a suggested evaluation method, not a published benchmark or a description of private model internals.

Prompt edits are difficult to test because the expected output is not a single exact file. A byte-for-byte snapshot comparison will reject harmless variations while saying little about whether the important content survived.

Build a small fixture set

Choose images you have permission to use: a product with readable text, a portrait, an object with fine edges, and a scene with repeating texture. Keep the input files unchanged between evaluations. Record the selected model or mode, prompt, aspect ratio, and date when available.

For a browser editor such as nano banana, start with one narrow edit per fixture. Changing background, color, framing, and lighting in the same request makes a failure hard to diagnose.

Test invariants instead of identical pixels

For each fixture, define a short acceptance checklist. A product image might require the same package shape, legible original label, and no invented attachments. A portrait needs identity and expression review. A patterned surface needs checks for repeated seams and distorted perspective.

Separate required checks from preferences. A more attractive result can still fail if it changes a product's identifying details. Log the failed check and keep the output that demonstrates it.

Compare changes fairly

When refining a prompt, keep the source and output format fixed. Repeat a small number of attempts if your budget permits, but report the number of runs and failures instead of presenting one selected image as typical performance.

Nano Banana AI provides image upload and text instructions in the browser. This article does not claim deterministic generation, guaranteed identity preservation, or an official relationship with a model vendor.

A practical release rule is simple: generation creates a candidate; a separate review approves an asset.

Website: https://nanobanana-ai.org/

Treat AI Photo Edits Like Changesets: A Practical Review Workflow

Fri, 23 Oct 2026 11:10:04 +0000

Disclosure: I work on Photo Tea. This is a proposed review workflow, not a claim that the product implements the code or automatically preserves every detail.

An image edit has two requirements: make the requested change and leave unrelated content alone. Checking only the first is how a clean background can hide a changed product label.

Write a small change contract

Before opening an ai photo editor, record three fields: change, preserve, and reject. For a product shot, change might be the background; preserve might include packaging geometry and label text; reject might include invented accessories or new shadows crossing the label.

Keep the original file. Give each attempt its own name rather than overwriting the last result. A useful record is:

{"asset":"bottle-01","revision":2,"change":"light gray background","preserve":["label","cap shape"],"decision":"needs-review"}

This is an example record for your own process, not a Photo Tea API payload.

Inspect the change and the invariants separately

First compare the full composition at the intended display size. Then inspect the label, silhouette, reflections, and contact shadow at full resolution. A successful background replacement does not compensate for an incorrect ingredient label.

Record failures by region, not just as a score. “Cap became wider” gives the next prompt a concrete constraint; “looks bad” does not. Change one instruction per attempt so you can understand which change helped.

Keep approval outside generation

Photo Tea offers prompt-based photo editing. The final publishing decision should still be explicit: approved, rejected, or needs manual repair. File existence and image dimensions are useful automated checks, but neither proves product accuracy.

Use only images you own or may edit, and check privacy requirements before uploading customer photos. For sensitive details, a conventional editor may be the better final step.

Website: https://phototea.art/

Why JPEG can blur colored text even at a high quality setting

Sun, 18 Oct 2026 11:12:46 +0000

A JPEG export can leave a soft fringe around colored text even when the image keeps its original dimensions. Before pushing the quality slider higher, check whether the encoder is reducing the resolution of the color channels. That process is called chroma subsampling.

Consider a small red label beside a gray button. Its edge has an abrupt color change. A cloudy sky usually has gentler transitions, so settings that suit that photograph may leave the label looking smeared.

Color has its own resolution

A common JPEG encoding path converts RGB into YCbCr. Y carries luma, a brightness-related signal; Cb and Cr carry color-difference information. Chroma subsampling reduces the spatial resolution of those color components. The decoded picture still has the same pixel dimensions.

With 4:4:4, each color-difference component has a sample at every pixel position. With 4:2:2, each has half the horizontal resolution. With 4:2:0, each has half the horizontal and half the vertical resolution. For a conceptual 4-by-4 patch, that means 16 samples per chroma component at 4:4:4, compared with four at 4:2:0. These are sample counts, not predictions of compressed file size. The TurboJPEG API documentation describes these sampling arrangements.

When decoding a subsampled image, the decoder reconstructs color samples for the full output grid. A narrow colored stroke can acquire a softer edge in that reconstruction. Inspect the small labels directly: fitting the whole screenshot into a preview can conceal the damage.

Quality and subsampling are different controls

In libjpeg-turbo's lossy JPEG encoder, the quality setting scales the quantization tables. Subsampling has its own control. Its command-line documentation explains that quality 100 still allows losses from subsampling and rounding. A high quality value does not, by itself, establish that full chroma resolution was retained.

An application may tie its quality slider to several encoder settings. Check the exporter you are using; the number 90 alone tells you too little to reproduce its output in another application.

Compare exports from the same source

Start with a screenshot containing small colored text. From that source, export two JPEG copies at identical dimensions and quality settings. Use 4:2:0 for one and 4:4:4 for the other if the encoder lets you choose. Put those settings in the filenames and keep a note of the encoder version. Someone checking your result should be able to recreate the exports.

View the copies at a consistent image zoom, including 100%, then inspect an enlarged crop of the label. Keep any resizing out of this first comparison. Otherwise, a resizing filter adds another explanation for a soft edge. Compare the downloaded files, because a preview in an export dialog may be scaled differently.

Treat this as an experiment to run on your own images. No benchmark measurements are reported here. If the two copies look alike, record that observation and investigate the other processing steps before attributing the problem to subsampling.

I work on Morphio, which offers HEIC conversion tools. When deciding on an output format, I would include small colored labels in the visual checks if they are part of the image. The encoder controls described above are not a statement about which settings Morphio exposes.

Choose a format for the content

For screenshots with text or diagrams, include PNG in the comparison. PNG compresses losslessly, so it can preserve the raster samples supplied to its encoder. It cannot restore details already lost in a previous JPEG export. MDN's image format guide discusses PNG and JPEG in this context.

If the destination requires JPEG, compare a 4:4:4 export with the subsampled copy. Other lossy encoding steps still affect both. Then inspect the image served by the destination page: an upload service may resize or recompress your file after you send it.

Canvas cropping: keep source pixels separate from output size

Sat, 17 Oct 2026 06:37:13 +0000

A crop box and an export size describe two different things. The crop box chooses pixels from the decoded source; the export size decides how many pixels to write. Keeping those numbers separate makes an image editor much easier to reason about.

Start with image pixels, not the preview rectangle

Suppose the decoded image is 320 × 240 pixels. You want the region beginning at (40, 24), with a width of 200 and a height of 160. That rectangle fits because 40 + 200 <= 320 and 24 + 160 <= 240.

The preview might be displayed at half size. In that case, a pointer position of 20 CSS pixels from its left edge represents 40 source pixels. Convert pointer coordinates using the actual displayed image rectangle before storing the crop. If the image is letterboxed inside a larger container, use the image rectangle rather than the container, or subtract the padding first.

For an image drawn without rotation, the conversion is:

const sourceX = (pointerX - imageRect.left) * source.width / imageRect.width;
const sourceY = (pointerY - imageRect.top) * source.height / imageRect.height;

Clamp the final rectangle to the source bounds and choose an explicit rounding rule. Do not let a partially outside selection silently become an unexpected export.

Pass both rectangles to Canvas

The nine-argument form of drawImage keeps the two jobs visible. For that 200 × 160 crop, a 500 × 400 export preserves the 5:4 aspect ratio:

canvas.width = 500;
canvas.height = 400;
ctx.drawImage(source, 40, 24, 200, 160, 0, 0, 500, 400);

The first rectangle belongs to the source image. The second belongs to the destination canvas. Setting the canvas bitmap dimensions matters: changing only its CSS width changes the preview, not the exported pixel dimensions.

Validate that the dimensions are positive and the crop fits the decoded image. Also apply a pixel budget before allocating a large canvas. A very long, narrow image and a square image can have the same pixel count but different side-length constraints, so check both.

Encode the result, then inspect it

Export through canvas.toBlob, handle a null result, and check the returned type. For PNG, the browser can preserve transparency. JPEG is useful when a photographic image needs a smaller raster file, but a quality setting does not change the crop geometry. When decoding an external URL, its cross-origin policy can affect whether the canvas is exportable; a local file selected by the user avoids that particular remote-origin workflow.

Keep SVG tracing as a separate decision

Resizing a raster image does not turn its pixels into vector paths. Tracing is another step, with choices about color detail and smoothing. For a flat-color motif, crop away irrelevant borders first, trace it, and compare the original and vector preview at more than one zoom level. Look at small gaps, corners and separate color regions before downloading.

A useful no-setup way to explore that sequence is the browser image workspace in JPG to SVG: crop or resize a local image, then send it to tracing without selecting the file again. Processing stays in the browser, and the SVG output contains paths. I help maintain the product.

How to Upscale Images for the Web Without Over-Sharpening: An Upscayl Workflow

Sun, 20 Sep 2026 05:36:35 +0000

An image can have more pixels and still look worse. Enlarging a compressed photograph may produce crunchy edges, waxy skin, or invented texture. For a website or product page, the goal is not the largest possible file. It is an image that remains clear at its actual display size without misrepresenting the subject.

This guide uses the browser-based Upscayl image upscaler to explain a preparation, enhancement, and review workflow. The steps focus on decisions you can repeat with your own images, not unverified performance scores.

Disclosure: I am affiliated with upscayl.app. This article refers specifically to that website and its browser interface; it should not be read as a guide to similarly named desktop software. This is not an independent comparative review. Features and credit requirements depend on current settings and account access.

Website: https://upscayl.app/

What Does AI Image Upscaling Change?

Ordinary resizing calculates additional pixels from existing ones. AI upscaling can also infer likely edges and textures from learned patterns. That can make an image look clearer, but inferred detail is not the same as recovered evidence.

This distinction matters for product labels, faces, artwork, and historical photographs. An enhancement that makes a tiny serial number look readable might have changed its characters. A cleaner face might no longer preserve the person's precise features. Evaluate fidelity as well as visual appeal.

Keep your original unchanged. Save enhanced copies under separate filenames so you can return to the source if a client questions a detail or if a later export requires different dimensions.

How Much Larger Does Your Image Need to Be?

Work backward from the layout. Suppose a photograph is displayed at 800 CSS pixels wide. A 1600-pixel-wide image can be a reasonable candidate for a high-density display, but the right delivery size also depends on responsive breakpoints, compression, and the user's device.

If the source is 800 pixels wide, start by evaluating a 2x output rather than automatically requesting 8x. A larger scale multiplies storage and review costs without necessarily adding useful detail. It may also exaggerate artifacts already present in the input.

For a product gallery, inspect the zoomed view as well as the thumbnail. A result that looks fine in a small card can look unnatural when a shopper opens the full image.

How to Prepare a Source Image Before Uploading

Choose the best available original, not a screenshot of a compressed social-media copy. Avoid repeated JPEG exports before enhancement: those exports discard information and can introduce edge artifacts that the model may amplify.

Crop only when the destination genuinely requires it. If you need several layouts, preserve a larger master rather than permanently cutting away useful composition. Straighten obvious rotation where necessary so you can compare the source and output consistently.

Use only images you own or have permission to process. For portraits or sensitive client material, review the website's current privacy and retention policies instead of assuming that a browser interface means all processing happens locally.

How to Use the Current Upscayl Browser Interface

At the time of inspection, the upload panel listed JPG, PNG, WEBP, and ZIP input options, a per-file size limit, and a visible batch limit. It also offered modes such as Standard, Portrait, Anime / Art, Face Restore, and Scratch Restore, along with scaling and output-format controls. Check these values in your own session because account limits can differ.

Upload one representative image before committing an entire batch.
Choose a mode that matches the image. Start with Standard for general photographs; test specialized modes only when they address a real problem.
Select a modest scale that meets your delivery dimensions.
Review the displayed credit cost and any optional face-enhancement setting.
Generate the output, compare it against the original, and download only after inspecting important details.

For a batch, choose a test image with the hardest characteristics: fine hair, small lettering, repeated fabric texture, or compression damage. A setting that works on a simple background may fail on those details.

Standard Enhancement vs Face Restoration vs Artwork Modes

General enhancement is a sensible starting point when the photograph already represents the subject well and mainly needs more usable pixels or clearer edges.

Face restoration is a more specialized decision. It can affect the appearance of facial details, so inspect eyes, teeth, skin texture, and identifying marks. For documentary or identity-sensitive use, a less dramatic result may be preferable.

Artwork-oriented enhancement should be judged on line continuity, edge cleanliness, color boundaries, and preservation of artistic intent. A mode that makes a photograph look detailed can add unwanted texture to flat-color illustration.

These are selection principles, not claims that every mode will outperform another. Compare outputs at the same viewing size and keep a note of which mode produced each file.

Why Do Upscaled Images Sometimes Look Artificial?

Over-sharpening often appears as bright or dark outlines around high-contrast edges. Excessive texture reconstruction can make smooth materials look rough. Strong facial processing can produce a polished but inaccurate face. Existing JPEG blocks can become more noticeable when enlarged.

Review at both the intended display size and a one-to-one pixel view. The first answers whether the image works for the audience. The second helps locate artifacts. Neither view alone is sufficient: extreme zoom can make harmless issues look severe, while a small preview can hide meaningful errors.

If the result is too aggressive, try a different mode, a smaller scale, or a better original. Do not keep upscaling previously enhanced copies in the hope that more passes will reliably recover the source.

Which Export Format Should You Choose?

The inspected interface offered JPG, PNG, and WEBP. Choose according to the destination rather than assuming one format is always superior.

JPG is useful for ordinary photographic delivery when lossy compression is acceptable.
PNG is useful when a lossless workflow or supported transparency is needed, although file sizes can be larger. Selecting PNG does not itself remove a background.
WEBP is useful for web delivery when supported by the destination and your content pipeline.

After using the online AI image enhancer, treat web optimization as a separate step. Generate appropriately sized responsive variants and avoid sending a huge master image to every mobile visitor.

Frequently Asked Questions

Can upscaling reliably recover unreadable text?

No. Small lettering can be altered or invented. For product labels, specifications, and legal text, obtain a higher-quality source or recreate the text from an authoritative original.

Should every image use the same settings?

Not necessarily. Group similar image types, test each group, and inspect representative results. Portraits, screenshots, product photography, and illustrations have different failure modes.

Is the largest output always the best one to publish?

No. The best publishing asset balances clarity, fidelity, dimensions, and loading cost. Archive the master separately from the optimized website version.

Before You Publish

Compare the result with the original, confirm no important feature has changed, test the image in the actual page layout, and check its file size. A useful enhancement preserves what matters while making the image easier to use. Bigger dimensions alone do not prove that you achieved that goal.

How to Compress, Resize, Convert, and Remove EXIF Data From Images Online

Fri, 18 Sep 2026 15:06:25 +0000

Working with images usually sounds more complicated than it actually is. Most of the time, you don't need Photoshop or another large image editor. You just need to make an image smaller, change its dimensions, convert it to another format, or remove some information stored inside the file.

The problem is that these jobs are often spread across different tools. You might find one website for compression, another for converting PNG to JPG, another for resizing, and another for checking image metadata.

That's why having a collection of image utilities in one place is useful. Image Tools Kit is built around exactly that idea, with tools for image compression, conversion, resizing, metadata, privacy, and several other image-related tasks.

Here is a practical look at how to handle some of the most common image tasks online.

Compressing an Image Online

Image compression is one of the simplest ways to reduce the size of an image without changing its dimensions.

For example, you might have a photograph that is 6 MB but only need to use it on a website. There's usually little reason to make visitors download the entire 6 MB file if a properly compressed version can look almost identical while being much smaller.

An image compressor reduces the amount of data stored in the file. The amount of compression you should use depends on the image and where you're going to use it.

For a website, moderate compression is usually a good starting point. You want the image to load quickly, but you also don't want obvious quality loss.

You can use the Image Tools Kit image compressor to reduce the size of an image before uploading it to a website, sending it to someone, or storing it online.

Image compression is particularly useful for:

Blog images
Website photographs
Product images
Social media graphics
Screenshots
Large camera photos
Images being uploaded to a CMS

One thing worth remembering is that smaller isn't always better. If you push compression too far, you can start seeing blurry details, blocky areas, and other artifacts. The goal is to find a reasonable balance between file size and image quality.

Compressing JPG Images

JPG, also written as JPEG, is one of the most common formats for photographs.

A modern smartphone or camera can produce surprisingly large JPEG files, especially when the photo is taken at a high resolution. If you're uploading those images to a website, compressing them first can save both storage space and bandwidth.

The Image Tools Kit JPG compressor can be used when you specifically want to optimize JPEG files.

JPG compression is generally lossy, which means some image information is discarded during compression. This is why repeatedly compressing and saving the same JPEG isn't a great idea.

It's better to keep the original photograph and create a compressed copy for the particular place where you're going to use it.

For example, your original might remain untouched on your computer while a smaller version is created specifically for your website.

Compressing PNG Images

PNG is a different story.

PNG is useful when you need transparency or want to preserve sharp graphics without the type of compression normally associated with JPEG. Logos, icons, screenshots, interface graphics, and illustrations are common examples.

The downside is that PNG files can become quite large.

If you have a PNG that is larger than it needs to be, you can use the Image Tools Kit PNG compressor to create a smaller version.

However, don't assume that PNG is automatically the best format for every image. A photograph saved as PNG can be much larger than the same photograph saved as a properly compressed JPEG or WebP.

The type of image matters.

A transparent logo and a photograph have very different requirements, so choosing the format first and then optimizing the file usually makes more sense than simply compressing everything in the same way.

Resizing an Image Online

Compression and resizing are often confused, but they solve two different problems.

Compression reduces the amount of data in the file.

Resizing changes the actual dimensions of the image.

Imagine you have a photograph that is 6000 × 4000 pixels. That's a perfectly reasonable resolution for an original camera photo, but it may be excessive for a website that displays the image at around 1200 pixels wide.

You could compress the 6000-pixel image, but you're still keeping millions of pixels that the visitor may never actually see.

This is where an image resizer is useful.

With the Image Tools Kit image resizer, you can create a version with dimensions that make more sense for its intended use.

Resizing can be useful for:

Website images
Blog thumbnails
Profile pictures
Product photos
Social media images
Gallery previews
Email attachments

If you know the maximum size an image will actually be displayed at, resizing it to something close to that size can make a significant difference.

For example, there isn't much benefit in uploading a 5000-pixel-wide photograph when the largest version on your website is only 1000 pixels wide.

Resizing Images for Websites

One of the easiest image optimization mistakes to avoid is uploading the original camera file directly to a website.

A phone might produce a 4000 or 5000-pixel-wide photograph, while the website might display it inside a 1000-pixel-wide content area.

The browser can scale the image down visually, but the visitor may still have to download the larger file.

A better approach is to resize the image before uploading it.

You can then compress the resized version as well.

For example:

Original:
4000 × 3000 pixels
5 MB

After resizing:
1600 × 1200 pixels
1.2 MB

After compression:
1600 × 1200 pixels
500 KB

The exact numbers will vary depending on the image, but the basic idea is important: resizing and compression can work together.

Creating Smaller Thumbnails

Thumbnails are another good example.

A thumbnail doesn't need to contain the same amount of information as the original image. If you're displaying a small preview in a blog listing or gallery, downloading a full-resolution photograph just to display a small box is wasteful.

An online thumbnail maker can create smaller versions for these situations.

You can use the Image Tools Kit thumbnail tools when you need consistent smaller versions of images without opening a full image editor.

Converting Images Between Formats

Sometimes the image isn't too large. It's simply in the wrong format.

Maybe you've received a PNG but need JPG. Maybe you're preparing images for a website and want WebP. Or perhaps an application you're using only accepts a particular file type.

An online image converter makes these jobs straightforward.

Image Tools Kit includes conversion tools for common image formats, including JPG, PNG, WebP, AVIF, GIF, and BMP.

There is one important thing to understand about image conversion: changing formats doesn't automatically make an image smaller.

For example, converting a JPEG photograph to PNG can actually make the file considerably larger.

The best format depends on what the image contains and what you're using it for.

Converting JPG to PNG

PNG can be useful when you need transparency or lossless image storage.

If you have a JPG that needs to be converted, the Image Tools Kit JPG to PNG converter can handle the format change without requiring a desktop image editor.

This is useful when a particular application or workflow requires PNG.

But if you're converting a photograph simply because you think PNG will always be smaller or better, there's usually no reason to do it. For ordinary photographs, JPEG or WebP may be a more practical choice.

Converting PNG to JPG

The reverse situation is also common.

You might have a PNG photograph or graphic that doesn't need transparency and want to create a JPG version.

The Image Tools Kit PNG to JPG converter can be used for this.

Remember that JPG doesn't support transparent backgrounds. If the original PNG has transparency, you'll need to account for that during the conversion.

Converting Images to WebP

WebP has become a popular choice for websites because it can provide good image quality at relatively small file sizes.

If you're working on a website, converting suitable images to WebP can be one option for reducing the amount of data browsers need to download.

The Image Tools Kit WebP converter can be used when you need to create WebP versions of existing images.

Whether WebP is the right choice depends on your website and the image itself, so it's worth checking the final result rather than converting everything automatically.

What Is EXIF Data?

EXIF is something many people don't notice until they start looking into image privacy.

EXIF stands for Exchangeable Image File Format. It refers to metadata stored inside image files.

Depending on the device and software that created the image, EXIF data can contain information such as:

Camera manufacturer
Camera model
Lens information
Date and time
Exposure settings
Image orientation
Software information
GPS coordinates

Most of this information isn't visible when you simply look at the photograph.

You can have a perfectly normal-looking photo that contains additional information inside the file.

How to View EXIF Metadata

Before removing metadata, you may want to see what's actually there.

An EXIF viewer lets you inspect the information stored inside an image.

The Image Tools Kit EXIF viewer can be useful when you want to check a photograph before publishing or sharing it.

This is also useful when troubleshooting images. Sometimes metadata such as orientation information explains why an image appears rotated differently in different applications.

For photographers, EXIF can be useful because it can contain camera and exposure information. For people sharing personal photographs, some of that information may not be necessary.

Removing EXIF Data From Images

If you don't need the metadata, you can remove it from the copy of the image you're going to share.

An EXIF remover removes metadata from the file while keeping the actual visual image.

You can use the Image Tools Kit EXIF remover when preparing photographs for a website, social media, forums, or other public places.

This is particularly worth considering with photographs taken on smartphones.

GPS Metadata and Image Privacy

GPS metadata deserves special attention because of the location information it can contain.

If a phone records GPS coordinates when a photograph is taken, those coordinates can become part of the image's metadata.

The photograph itself might not reveal where it was taken, but software that reads EXIF information could potentially extract the coordinates.

That doesn't mean every smartphone photograph contains GPS information. It depends on the device, camera application, and settings.

Still, if you're publishing personal photographs publicly, checking the metadata first is a sensible habit.

Image Tools Kit also includes tools for removing GPS-related metadata if that's specifically what you're concerned about.

Should You Remove EXIF From Every Image?

Not necessarily.

EXIF data isn't automatically bad.

A photographer may want to keep information about the camera, lens, ISO, shutter speed, aperture, or date. That information can be useful for organizing a photography library or understanding how a photograph was taken.

The decision really depends on what you're doing with the image.

If you're maintaining an original photography archive, keeping the metadata can be useful.

If you're posting a personal photograph publicly and have no reason to share its metadata, removing it makes more sense.

A simple approach is to keep the original file and remove metadata only from copies that you're going to publish.

A Practical Image Optimization Workflow

For most website images, you don't need to use every image tool available. A simple workflow works well.

Start by checking the image dimensions.

If the image is much larger than the size you actually need, resize it first.

Next, choose an appropriate format. Photographs often work well as JPEG or WebP, while graphics requiring transparency may be better suited to PNG or another format that supports transparency.

After that, compress the image.

If you're publishing a personal photograph, check the EXIF data before uploading it. If you don't need the metadata, remove it.

Then upload the optimized copy to your website.

Keeping the original file is a good idea because you can always create another optimized version later. Once you've heavily compressed or resized an image, you can't recover the original quality simply by reversing the process.

Why Use Multiple Image Tools in One Place?

There are plenty of websites that can compress an image, convert a JPG, or remove EXIF data.

The annoying part is finding a different site every time you have a different job.

One site handles compression. Another handles resizing. Another converts WebP. Another lets you inspect metadata.

That's where a larger image toolkit becomes useful.

Image Tools Kit puts these types of utilities together, so you can move from one image task to another without installing a large desktop application or searching for another tool every time.

It isn't about needing a complicated tool for every image. In many cases, the opposite is true. You just want to open the right utility, do one job, and move on.

For someone working on a website, preparing images for articles, managing photographs, or dealing with different file formats, having those basic utilities in one place can save a surprising amount of time.

The next time you have an image that's too large, too big in dimensions, in the wrong format, or carrying metadata you don't want to publish, you don't necessarily need a full image editor.

You can use the specific tool you need, whether that's an image compressor, image resizer, image converter, EXIF viewer, or EXIF remover, and get the file ready for whatever you're using it for.

From Book-Cover Illustrator to Indie Developer: Maxim Mitenkov’s Journey of Building for His Own Pai

Fri, 11 Sep 2026 09:22:00 +0000

From Book-Cover Illustrator to Indie Developer: Maxim Mitenkov’s Journey of Building for His Own Pain

A CoderLegion Developer Story featuring Maxim Mitenkov

Interview conducted and edited by Mehadi Hasan, Community & Editorial Team at CoderLegion

What happens when an illustrator gets tired of doing the same task over and over?

You build a tool.

For Maxim Mitenkov, that meant turning years of experience as a book-cover illustrator into a growing journey as an indie developer.

Maxim has spent more than fifteen years working in design, primarily creating book covers and illustrations. But processing dozens of images every month — resizing, cropping, compressing, and converting them for different destinations — became a problem he couldn't ignore.

The obvious solutions weren't good enough.

Photoshop Actions broke when the source changed. Scripts became difficult to maintain. Cloud-based image processors created a privacy problem when the files belonged to clients and hadn't been published yet.

So Maxim started building.

Today, he is the solo founder of Image Pipeline, a batch image processor that runs entirely in the browser.

His journey combines software engineering, illustration, product development, privacy, and the realities of building an indie product around a problem he personally understands.

From Computer Science to Illustration — and Back to Code

Maxim's relationship with technology didn't actually begin recently.

He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998, graduating as an Engineer.

Professionally, however, his career developed around design.

For more than fifteen years, he has worked as a book-cover illustrator, along with illustration and some branding work.

The tools were familiar:

Photoshop.

Illustrator.

A drawing tablet.

The creative side of the work was what mattered.

But there was another side to the job that was much less interesting.

Every month, Maxim would prepare 50 to 100 images for portfolios, clients, Behance, Pinterest, and other destinations.

Resize.

Crop.

Compress.

Convert.

Repeat.

Every hour spent repeating those tasks was an hour that wasn't spent drawing.

The Problem That Started Everything

The repetitive image-processing work eventually became too obvious to ignore.

Photoshop Actions seemed like a solution, but they fell apart when clients supplied images with different aspect ratios.

ImageMagick scripts worked, but only as long as Maxim remembered how they worked months later.

Cloud converters created an even bigger problem.

Client artwork could be unpublished or covered by an NDA.

Uploading it to someone else's server simply wasn't something Maxim wanted to do.

The problem was specific enough that he already knew what the product should look like:

Open a link, drag files in, hit a button, get a ZIP.

No account.

No upload.

No subscription.

That simple specification became Image Pipeline.

Becoming a Developer Because There Was a Problem

Maxim didn't originally set out to become a software developer.

Instead, he realized that the person who could write the script was also the person who could build the interface around it.

He started learning JavaScript.

Then he moved to React when plain JavaScript started becoming limiting for what he wanted to build.

Eventually, the code became a product.

His transition wasn't driven by a career plan.

It was driven by necessity.

"I did not become a developer on purpose. I became one because there was a problem and nobody else was going to fix it."

That idea captures much of Maxim's approach to development.

He isn't building software simply because software is interesting.

He's building because he sees something that could work better.

Why Image Pipeline Runs Entirely in the Browser

One of the most important decisions in Image Pipeline was privacy.

Rather than processing images on a backend, Maxim designed the application so the work happens inside the browser.

Resize.

Filters.

Format conversion.

ZIP creation.

All of it happens on the user's machine.

There is no server receiving the images.

There is no image-processing queue.

There is no server-side image storage.

The result is a privacy model based on architecture rather than marketing.

Maxim describes the claim simply:

"I can't see your images."

That's a powerful difference.

The product doesn't need to promise that someone won't access your files.

The files don't need to reach the server in the first place.

Building for Yourself Has an Advantage

Maxim was his own first user.

That changed the way he built the product.

He didn't need to survey users to decide which features were important in the beginning.

He already knew what he repeatedly needed.

Resize.

Crop.

Compress.

Export.

Those were the operations he performed constantly.

But building for yourself also creates blind spots.

Maxim discovered this after launching.

His first public review on AlternativeTo was only two stars.

The reviewer wanted brightness, contrast, and exposure controls. The preview was too small, and multiple export wasn't working.

Some of those requirements had never occurred to Maxim.

But the criticism was useful.

He fixed the problems.

The next review was five stars.

That experience led to one of the clearest lessons from the project:

"Your pain gets you version one. Other people's pain gets you everything after."

Launching Before Everything Was Perfect

Image Pipeline launched with nine nodes.

There was no elaborate onboarding system.

No extensive FAQ.

No attempt to build every possible feature before allowing people to use it.

Maxim wanted to find out whether anyone actually wanted the product.

That decision quickly exposed several lessons.

Minimum Isn't Readiness

The features Maxim personally needed weren't necessarily all the features other users expected.

An image-processing application naturally creates expectations around things like brightness, contrast, and exposure.

His own workflow had created a blind spot.

Preview Is Trust

The original preview wasn't good enough.

Users needed to see what was going to happen before processing their images.

Maxim rebuilt it with a larger live image, zoom functionality, and a before/after slider.

The preview eventually became one of the strongest parts of the product.

Feedback Beats Planning

Users also requested ways to change the mood and feeling of images.

Instead of spending weeks planning the feature, Maxim built an emotion filter in a couple of days.

The experience reinforced another principle:

"Launch early. The only expensive failure is launching late and finding out nobody wanted it."

The Technical Choice He Didn't Make

One of the most interesting technical decisions in Image Pipeline was choosing not to use WebAssembly.

WASM seemed like the obvious answer.

It's fast.

It's powerful.

It's designed for exactly the kind of computational work browsers increasingly need to perform.

But Maxim wasn't optimizing for benchmarks alone.

He wanted the application to open quickly, including on mobile devices.

WebAssembly would introduce additional download size, build complexity, and compatibility concerns.

So the image-processing core remained plain HTML5 Canvas code.

The application processes pixel buffers directly through browser APIs.

It may not be the fastest possible solution for enormous images.

But Maxim's goal wasn't to win an artificial benchmark.

It was to build something that solved the real problem efficiently.

The engine stayed small and relatively boring.

And that was exactly the point.

Why React Flow Was the Right Engineering Decision

The visual pipeline required a node-based interface.

Maxim could have built the node editor himself.

But that would have meant spending significant time solving problems that another project had already solved.

Instead, he chose React Flow.

It provided capabilities such as:

Drag and drop
Connections
Connection validation
Zooming
Node-based interaction

That choice saved development time.

Rather than spending a month building and debugging a custom node canvas, Maxim could spend that time improving the actual product.

For him, that was the better engineering decision.

You don't prove that you're a good developer by rebuilding everything yourself.

Sometimes the better engineering decision is knowing what not to build.

From Nine Nodes to a Growing Product

Image Pipeline has grown significantly since its initial launch.

Maxim's profile notes that he shipped 14 node types in six weeks.

The product has expanded with functionality including:

Blur and sharpen
Denoise
Watermarking
Rotation
Color temperature
HSL adjustments
Emotion filtering

The pattern behind many of these features remains simple.

Someone asks for something.

Maxim considers whether the request makes sense.

Then he builds it.

The product is evolving through actual usage rather than through a huge feature roadmap designed in isolation.

Privacy Isn't Just a Checkbox

Maxim sees privacy as more than a feature of Image Pipeline.

He believes the broader web is moving toward more client-side processing because users are becoming increasingly uncomfortable with uploading their data everywhere.

Every service wants an account.

Every signup form wants an email address.

Every cloud-based tool requires some level of trust.

Image Pipeline takes a different approach.

If the processing can happen locally, why send the user's files somewhere else?

For Maxim, privacy isn't a promise added after the architecture.

It's part of the architecture itself.

Building as a Solo Founder

Maxim's development schedule doesn't look like a traditional software job.

He describes it as switching.

Mornings are for illustration.

Days are for code.

Evenings are often for testing.

Image Pipeline was built in the gaps between paid illustration projects.

A client finishes early.

A day becomes available.

Instead of waiting for the perfect schedule, Maxim uses the time to build.

The hardest part isn't necessarily finding the hours.

It's switching between two very different mental modes.

Illustration is about emotion, composition, color, and visual judgment.

Programming is about logic, behavior, and systems.

Moving between the two takes time.

Sometimes that transition requires a coffee.

Sometimes a walk.

Then it's back to the other world.

How Design Influenced His Code

Maxim's background in illustration naturally influences how he builds software.

After spending years thinking about composition, color, typography, and visual communication, he can't simply ignore the interface.

The nodes need to look good.

Typography needs to be readable.

The preview needs to communicate trust.

Design isn't something that gets added at the end.

It is part of the product.

But the influence works in the opposite direction too.

Programming changed the way Maxim thinks about design.

Once you understand how software works, you start seeing pipelines everywhere.

Illustration itself is a pipeline.

Sketch.

Line.

Color.

Light.

Detail.

Each stage takes an input and produces an output.

Building software around workflows made Maxim more conscious of his own creative process as well.

What He's Building Next

Image Pipeline continues to evolve.

The emotion filter is planned for another version, this time driven by real data rather than matrices manually tuned until they looked right.

Maxim is also exploring Web Workers for client-side heavy lifting.

Outside the core product, he's thinking about another problem from his own workflow.

Processing images is only one part of preparing a portfolio.

Organizing, tagging, and exporting those images for different platforms is another task that still takes manual work.

That has led him toward the idea of a portfolio preparation tool.

Typography is another area he is interested in.

After fighting with fonts every day, he suspects other designers have similar frustrations.

The pattern remains the same.

Find a problem.

Understand it.

Build something.

Use it yourself.

Then see whether the problem exists for other people too.

Building From 0 to Revenue

Maxim's profile describes his current focus as growing Image Pipeline from 0 to revenue.

The product has already passed several milestones:

Launched on Product Hunt
Received a 5★ review on AlternativeTo
Listed on Launch Llama
Shipped 14 node types in six weeks
Reached 46 passing tests
Maintained zero backend image processing

But the product is still evolving.

That's important because Maxim isn't presenting the journey as finished.

He's still experimenting.

Still responding to users.

Still adding features.

Still questioning his technical decisions.

And still building for himself.

What Coding Changed About His Career

Maxim's story doesn't fit the traditional idea of a developer journey.

He has a formal engineering education.

He built a career in illustration.

Then he returned to software through a problem he personally experienced.

Today, he sits between several worlds:

Design.

Illustration.

Programming.

Product development.

Indie entrepreneurship.

That combination is what makes his journey particularly interesting.

His development experience didn't replace his creative background.

It extended it.

His design experience didn't disappear when he started coding.

It became part of how he builds software.

The Lesson: Build From Your Own Pain

There is a simple principle running through Maxim's entire journey.

The best product idea may already be sitting inside your own frustration.

For Maxim, it was processing hundreds of images.

For someone else, it might be a workflow at work, a repetitive task, a missing tool, or a problem nobody has bothered to solve properly.

You don't always need to start with a startup idea.

Sometimes you just need to notice the thing you keep doing manually.

Then ask:

Why am I still doing this?

That question took Maxim from Photoshop and Illustrator to JavaScript, React, Canvas, and eventually a product used by designers beyond his own workflow.

His own profile sums up the philosophy well:

"Ship when it's embarrassing, not when it's perfect."

But there's an important second half to that idea:

Fix the bugs users actually complain about.

That's perhaps the most practical lesson from Maxim's journey.

Build early. Listen carefully. Keep improving.

About Maxim Mitenkov

Maxim Mitenkov is a book-cover illustrator, engineer, and indie developer from Belarus.

He studied Computer Science and Radioelectronics at Belarusian State University of Informatics and Radioelectronics (BSUIR) from 1993 to 1998.

Today, Maxim is the solo founder of Image Pipeline, a browser-based batch image processor designed around privacy and client-side processing.

His technology stack includes:

React
TypeScript
JavaScript
HTML5 Canvas
Tailwind CSS
Vite
Zustand
Node.js
Vercel
Git

He is currently exploring Web Workers for client-side processing, emotion-driven image filters, and growing Image Pipeline from 0 to revenue.

He has launched Image Pipeline on Product Hunt, earned a 5★ AlternativeTo review, shipped 14 node types in six weeks, and built the product with zero backend image processing.

View Maxim's full CoderLegion profile:
https://coderlegion.com/user/Maxim Mitenkov

About This Developer Story

Developer: Maxim Mitenkov

Series: CoderLegion Developer Stories

Interview conducted and edited by: Mehadi Hasan, Community & Editorial Team, CoderLegion

This Developer Story is based on Maxim Mitenkov's interview responses and his experience building software alongside his professional career as an illustrator.

I Built a Batch Image Processor with Zero Backend — Here's How

Tue, 18 Aug 2026 10:40:50 +0000

title: "I Built a Batch Image Processor with Zero Backend — Here's How"

canonical_url: https://imagepipeline.art

I process between 50 and 100 images every month. Portfolio pieces for Behance. Pinterest pins in three aspect ratios. Client deliverables that need to be web-ready, print-ready, and social-ready — all from the same source file.

For years I had three options. All of them were bad.

The Problem

Photoshop Actions worked once. Then a client sent vertical covers. The Action cropped them wrong. Then I needed PNGs for one project and WebPs for another. I ended up with twelve duplicated Actions, each with a slightly different suffix, and a folder full of files named final_v3_actual_FINAL.jpg.

ImageMagick scripts were fast. But three months later I opened a script and had no idea what ^ meant or why I chose center gravity. I needed to add a watermark. I needed to skip images smaller than 800px. I needed to see if the crop looked right before processing a hundred files.

Cloud converters were convenient. They also required me to upload client artwork — sometimes unpublished book covers under NDA — to someone else's server. "Theoretical risk" is not a phrase I want in the same sentence as "client contract."

The Realization

I didn't need a faster Photoshop. I didn't need a simpler ImageMagick. I needed a tool that combined three things:

Privacy. My files stay on my machine.
Visual feedback. I see what the pipeline does before I run it.
Zero setup. I open a link and start working.

Nothing I tried offered all three. So I built it.

What I Built

Image Pipeline is a node-based batch image processor that runs entirely in your browser.

You drag images in. You build a pipeline by connecting nodes: Load → Resize → Crop → Compress → Export. You click Process. Everything happens via Canvas API in your browser tab. Images never touch a server. You download a ZIP.

No signup. No installation. No credit card to "try it free."

The Technical Stack

When I say "zero backend for image processing," I mean it. The entire image manipulation layer is client-side:

Image decoding: Native FileReader + Image constructor
Manipulation: HTML5 Canvas API (drawImage, toBlob, getImageData)
Compression: Canvas toBlob with quality parameter
ZIP generation: JSZip, entirely client-side
Hosting: Static HTML/JS on Vercel

The "backend" that exists is minimal: 16 Vercel Edge Functions for rate limiting, payment verification (USDT on Tron), and email receipts. None of them touch your images.

Why No WebAssembly?

I intentionally avoided WebAssembly and heavy libraries. The app loads fast, works on old devices, and doesn't require users to download 5MB of WASM binaries just to resize a JPEG.

Why React Flow?

The node editor is built with @xyflow/react. It gives me drag-and-drop nodes, connection validation, and a clean API — without building a canvas renderer from scratch. The visual pipeline is the core UX, not a gimmick.

The Node System

Currently 14 node types:

Node	What It Does
Load	Accepts input images
Resize	Changes dimensions, fit modes, algorithms
Crop	Crops to region with position presets
Compress	Reduces file size with quality slider
Format	Converts between JPG, PNG, WebP
Watermark	Adds text overlay
Denoise	Reduces image noise
Brightness	Adjusts luminance
Contrast	Adjusts tonal range
Exposure	Adjusts light intensity
Saturation	Adjusts color intensity
Emotion Filter	Applies mood-based color grading (Joy, Sadness, Calm, Tension)
Rename	Batch renaming with patterns
Export	Output settings, ZIP generation

Each node has a live preview. Click a node, see before/after. Adjust settings, see changes in real time. The preview processes only a thumbnail (200px), so it's instant — the full batch runs only when you hit Process.

The Monetization Model

I didn't want subscriptions. As a user, I hate discovering a tool, liking it, then hitting a paywall that demands my credit card every month.

Free: 10 files/day, all nodes, all features
Pro ($10 one-time): Unlimited files, unlimited nodes
Lifetime ($30 one-time): Pro forever

Payments in USDT (TRC-20). No Stripe, no PayPal, no recurring charges. Verification happens via TronScan API with a Trongrid fallback. If the API is down, the client falls back to localStorage counters — the app never breaks.

What I Learned

Shipping beats perfection. I launched with 9 nodes, a basic landing page, and no onboarding. The first user on AlternativeTo gave me 2 stars and a list of complaints: "missing brightness, contrast, exposure," "preview is tiny," "multiple export broken."

Five days later I shipped Brightness, Contrast, Exposure, fixed the preview (300px + compare modal), fixed Multiple Export, and added Emotion Filter + Saturation as bonuses. The next review was 5 stars.

Users will tell you what to build. I never planned an Emotion Filter node. Someone asked about "applying mood to images" in a comment. I researched color matrices, built 5 emotion presets, and shipped it in two days.

Privacy is a feature, not a footnote. Every third comment mentions "images never leave the device" as the primary reason to try Image Pipeline. In a world of cloud-everything, client-side processing is a differentiator.

Try It

If you batch-process images regularly and none of the existing tools fit your workflow cleanly:

👉 imagepipeline.art

Free tier: 10 files per day. One-time purchase for unlimited.

If you're a developer and prefer CLI — honestly, stick with ImageMagick. It's unbeatable for automation. This tool is for everyone else who got tired of the trade-offs.

Maxim Mitenkov is a book cover illustrator and indie developer. He built Image Pipeline because he was tired of uploading client artwork to cloud services just to resize a batch of images.