DEV Community: Image Convert

How I Built a Reproducible Game Release-Date Forecast from Public Timelines

Image Convert — Wed, 02 Sep 2026 14:39:20 +0000

Release-date discussions often collapse three very different things into one sentence:

what a studio has officially announced,
what the public production timeline shows,
what the writer predicts.

I wanted a small, reproducible method that keeps those layers separate. I tested it on Black Myth: Zhong Kui, whose August 20, 2026 gameplay reveal created a fresh wave of “2027 or 2028?” speculation.

1. Define the evidence schema

For each game, I store only fields that can be tied to a dated source:

project
milestone_type
milestone_date
source_url
date_precision
confidence
notes

date_precision matters. “Development began in January 2004” is not equivalent to “development began sometime in 2019.” If a source gives only a year or a range, the calculation must stay a range too.

2. Separate public timeline from production timeline

These are not interchangeable:

Public timeline: first substantial public gameplay → launch
Production timeline: documented development start → launch

For Black Myth: Wukong, the public comparison is straightforward:

August 2020 gameplay reveal
→ August 20, 2024 launch
≈ 48 months

That does not prove Zhong Kui needs another 48 months. Wukong was Game Science’s first production at that scale; a second large action RPG starts with more shipping, engine, console, localization, and QA experience.

3. Use comparable sequels, but preserve uncertainty

I used three documented comparisons:

Series	First entry	Second entry	Approximate change
Horizon	72 months	50 months	31% shorter
Star Wars Jedi	60 months	40–45 months	25–33% shorter
Assassin’s Creed	46 months	24 months	48% shorter

The reduction is calculated as:

(first_cycle - second_cycle) / first_cycle

These are reference cases, not a prediction model. A sequel may reuse knowledge and tooling, but increased scope can erase the time saved. The Jedi comparison also needs lower confidence because its starting point is not an exact month.

4. Turn one date into competing hypotheses

For Zhong Kui, an August 2027 hypothesis creates two measurable intervals:

August 2025 announcement → August 2027 = 24 months
August 2026 gameplay reveal → August 2027 = 12 months

The first interval looks plausible beside the faster sequel examples. The second is aggressive: twelve months from a work-in-progress gameplay presentation to launch leaves limited room for content completion, platform certification, localization, and QA.

That is why my output is not “the game releases in August 2027.” It is:

August 2027 is an aggressive but defensible forecast window, not an announced date.

5. Make the forecast falsifiable

A useful forecast should say what would strengthen or weaken it.

Signals that would strengthen August 2027:

first-party store pages,
an official release window,
preorders or ratings-board activity,
a public build that looks close to release quality.

Signals that would push the estimate toward 2028 or later:

continued large-scale system experimentation,
visible redesigns,
no commercial launch signals by mid-2027,
official language continuing to describe the project as early.

This turns a hot take into a checklist that can be updated when new evidence arrives.

6. Publish the calculations, not just the conclusion

The complete Zhong Kui case includes the milestone dates, source links, interval arithmetic, comparison caveats, and alternative 2028 scenario:

Black Myth: Zhong Kui release-date forecast — full evidence and calculations

The main lesson is broader than one game: precision in the output cannot exceed precision in the evidence. If a source says “before late 2019,” the result is a range. If the studio has announced no date, the conclusion must remain a forecast. That small discipline makes timeline analysis much easier to audit—and much harder to turn accidentally into misinformation.

Designing a Browser Image Compressor That Actually Stays Under 20 KB

Image Convert — Tue, 01 Sep 2026 16:27:41 +0000

“Compress to 20 KB” sounds like a single encoder setting. It is not.

Image encoders accept inputs such as quality and dimensions, but they do not guarantee an exact output byte count. If an application form rejects anything at or above 20,000 bytes, a compressor needs a bounded search strategy and a strict final measurement.

Here is the approach used in Image Convert.

Convert the target to bytes once

The interface supports decimal KB and MB:

1 KB = 1,000 bytes
1 MB = 1,000,000 bytes

So a 20 KB target becomes 20,000 bytes. The accepted target range is 1,000 through 100,000,000 bytes.

The success predicate is intentionally strict:

function isBelowTarget(outputBytes, targetBytes) {
  return outputBytes < targetBytes;
}

An output of exactly 20,000 bytes does not pass a 20 KB limit. This avoids a common UI bug where a file displays as “20 KB” after rounding but is rejected by the destination.

Keep an already-valid original

If the source file is already below the target and the output format is unchanged, re-encoding would only add work and could reduce quality.

The compressor returns the original bytes in that case:

if (source.size < targetBytes && outputType === sourceType) {
  return keepOriginal(source);
}

This path still needs validation. The source format must be supported and decoded dimensions must stay inside the application's safety limits.

Separate encoder search from acceptance

Image Convert uses browser-image-compression 2.0.2 as the direct raster compression engine. The engine receives a target and performs a bounded quality search, but the application does not treat the engine's requested maximum as proof of success.

Every returned Blob is measured again:

const candidate = await encode(source, options);

if (candidate.size === 0) {
  throw new Error("The image encoder returned an empty result");
}

if (candidate.size < targetBytes) {
  return candidate;
}

That second measurement is important. The user-facing promise belongs to the application, so the application must verify it.

Use a bounded three-round strategy

The search uses at most three rounds. Each encoder round is limited to seven iterations.

The first round keeps the original resolution and starts at 0.92 quality. If that candidate is still too large, later rounds reduce the maximum dimension and try again.

This avoids an unbounded loop and gives the UI a clear failure state. A target can be infeasible, especially for a visually complex image, a format with limited compression flexibility, or an extremely small byte limit.

Reduce dimensions using the byte ratio

When a candidate is too large, the next maximum dimension is derived from the relationship between the target and the measured candidate:

const ratioScale = Math.sqrt(targetBytes / candidateBytes) * 0.9;
const scale = Math.min(0.8, ratioScale);
const nextLimit = Math.floor(currentLimit * scale);

Why the square root?

For similar image content, the pixel count changes approximately with the square of a linear dimension. If the desired byte count is one quarter of the candidate, a rough first estimate is to reduce width and height to about one half.

The additional 0.9 factor leaves headroom, while the 0.8 cap guarantees a meaningful reduction between rounds. The next limit is also clamped below the current value so the search always progresses.

This is an estimate, not a mathematical guarantee. Image complexity, format, transparency, and encoder behavior all affect the result. That is why every round ends with a real byte measurement.

Preserve failures instead of creating misleading downloads

After three safe attempts, an oversized candidate is not presented as a successful download.

The error records:

the requested target
the smallest candidate produced
a clear “could not be compressed below” message

In a batch, other successful files remain available. A ZIP contains successful results only. An infeasible item contributes no download.

This is better than relabeling an oversized result, rounding its displayed size down, or silently uploading the file to a server fallback.

Keep the process local and cancellable

The selected source, target setting, decoded pixels, intermediate candidates, final images, and ZIP stay in the browser. The compressor disables the library's default Worker/CDN fallback and does not switch to a cloud service when local processing fails.

The operation also accepts an AbortSignal and progress callback. Cancellation should stop the active search, while queue removal and unmounting should release retained Blobs, canvases, and object URLs.

Explain the quality tradeoff

A strict byte target can require both lower encoder quality and smaller pixel dimensions. Users should compare the result with the source before relying on it.

PNG can be especially difficult for tiny targets. JPEG and WebP are lossy when re-encoded. Metadata and animation are not preserved. Browser memory and maximum canvas dimensions also put practical limits on large sources.

The practical version of this workflow is documented in How to Compress an Image to 20KB, including decimal-byte behavior, batch results, and what happens when the target cannot be reached.

Building a Reliable Browser-Local HEIC-to-JPG Batch Workflow

Image Convert — Tue, 01 Sep 2026 13:57:58 +0000

Converting one HEIC photo in a browser is mostly a decoding problem. Converting a batch is a workflow problem.

A useful batch converter has to keep files isolated, avoid exhausting memory, preserve successful results when one source is damaged, and make the output limitations clear. Here is the architecture I use for that workflow.

Keep the processing boundary explicit

The selected HEIC or HEIF files should stay inside the browser. The decoder can run as a self-hosted WebAssembly runtime, while the page itself still performs ordinary network requests for HTML, scripts, and optional analytics.

Those two facts are compatible:

Page delivery can use the network.
Source files, full file names, decoded pixels, generated JPG files, and ZIP archives do not need to be uploaded for processing.

For Image Convert, both HEIC tools use a pinned, self-hosted libheif 1.23.1 runtime. There is no server fallback if local decoding fails.

Treat every file as its own state machine

A batch should not be represented by one global success flag. Each file needs an independent state such as:

queued
decoding
encoding
ready
failed
removed

That separation matters when one file is unsupported or damaged. A failure should not erase the JPG files already produced from other inputs.

The user should be able to see which file failed, why it failed, and which files are still downloadable. If a ZIP option is offered, it should contain successful results only.

Prefer conservative processing over maximum concurrency

HEIC decoding can hold a compressed source, decoded pixels, a canvas or image buffer, and an encoded JPG at the same time. Starting many large photos in parallel can multiply that memory cost quickly.

Sequential processing is slower on paper, but it is easier to reason about and usually more reliable across laptops, phones, and memory-constrained browser tabs. A small, documented concurrency limit can also work, but it should be chosen deliberately rather than by mapping every file to a Promise at once.

After each item finishes, release temporary buffers and canvases that are no longer required. Revoke object URLs when an item is removed or after its download URL is no longer retained.

Start the default flow after validation

For a straightforward HEIC-to-JPG task, file selection can start the validated default conversion automatically. The important word is validated.

Before decoding, check the accepted extension and MIME information available from the browser, apply file and dimension safeguards, and map known failures to clear messages. Do not silently send an unfamiliar file to another service.

Automatic start works well here because the default output is unambiguous. A tool that creates one ordered PDF or opens a crop editor needs a different loaded-state workflow.

Make output limits visible

JPG is a lossy format. A converted photo may also lose metadata, and a Live Photo is not preserved as an interactive photo-and-video pair. Color and gamma behavior can vary across browser decoding and encoding paths.

The interface should explain those limits before users mistake “converted successfully” for “identical to the source.”

A practical completion checklist is:

Open representative JPG results before deleting the originals.
Keep the HEIC sources until the destination accepts the JPG files.
Expect metadata to be reduced or absent.
Treat Live Photos as still-image conversion unless motion handling is explicitly implemented.
Split very large batches when browser memory becomes a constraint.

Design the batch around recovery

The best batch experience is not the one that assumes every file succeeds. It is the one that makes partial success easy to understand and recover.

A damaged source should produce a useful per-file error. Other successful files should remain available. Clearing the queue should release retained resources. Downloading a ZIP should never include failed or incomplete items.

I wrote a more detailed, task-focused walkthrough in How to Batch Convert HEIC to JPG in Your Browser, including practical uses, local-processing boundaries, and output limitations.