Suppose a preview stores its transform before a temporary translation. Keep the saved matrix if you intend to apply that earlier transform again. This snippet assumes ctx is a valid 2D drawing context with the identity transform at the start:

const saved = ctx.getTransform();
ctx.translate(40, 0);
console.log(saved.e); // 0
console.log(ctx.getTransform().e); // 40
ctx.setTransform(saved);

The last line applies the stored matrix. The stored object affects the context only when you apply it. If you edit a matrix value, call setTransform() when you want the context to use it.

For a photo preview with several drawing stages, label the stored matrix by the stage it belongs to. A transform snapshot covers the matrix, not the entire drawing state. Make the image and annotation stages explicit about which transform they use.

Reference: MDN getTransform.

The default is true. For a pixel-art preview, you can set it to false before drawing an enlarged source. Compare the settings with the same source and destination dimensions.

For a temporary draw, call ctx.save(), assign the smoothing setting, draw the decoded image, and then call ctx.restore(). This keeps the changed setting from being carried into subsequent work that uses the restored state. Make sure restoration also happens if surrounding application code throws.

Inspect the canvas at the size used by the actual preview. A separately scaled page screenshot is another rendering step and should have its viewing conditions recorded. Keep the chosen setting beside the export record if the result is used for delivery.

I work on Morphio and write about browser image workflows. This note concerns Canvas drawing state, without claiming how any particular product implements resizing. Reference: MDN imageSmoothingEnabled.

Keep the controller with the job identifier. When the user cancels, call that job's controller.abort(). Do not use an older job's cancel control to stop a newer upload that now occupies the same result panel.

With no custom reason, aborting uses an AbortError reason. A canceled attempt should have its own interface state rather than being labeled as an accepted image. Start a retry with a new controller instead of reusing an already-aborted signal.

The MDN abort() reference describes cancellation of fetch and response consumption. Treat the server's saved state as a separate application question: a browser cancel action is not a deletion request to the upload service.

I work on Morphio, our image project at https://morphio.online/. These notes describe image preparation and review; they do not require a particular editing tool.

Use progress information to describe transferred bytes. When upload.load fires, move the interface to a waiting-for-response state if the request has not finished. Check the request's HTTP status and the response expected by the application before presenting an accepted result.

Report request failures and application rejections explicitly. A server can reject an image after receiving its bytes, so a progress bar reaching its end is insufficient evidence of acceptance.

Test that distinction with a sample the server deliberately rejects. Record the upload event and the final response separately, then check that the interface reports the rejection.

Source: MDN XMLHttpRequest.upload.

For a bitmap used only for one canvas draw, a try/finally around the draw can make cleanup explicit. Create the bitmap before entering that block, draw it inside try, and call bitmap.close() in finally. Handle a failure to create the bitmap separately because no bitmap exists to close in that case.

If another operation still needs the same bitmap, the first draw is not its final use. Assign cleanup to one owner and close the bitmap after its required uses finish. Do not hand a closed bitmap to the next job.

Test the failure path as well as the successful draw. The cleanup path should run when drawing throws after a bitmap has been created.

Source: MDN ImageBitmap.close().

I work on Morphio, and this note is part of the image-workflow guidance I maintain.

A small sequence is: create an Image, assign its src, then await image.decode() inside try/catch. Only replace the displayed image after that await succeeds. Show a failure state from the catch branch instead of leaving the interface with a success message.

Keep this check separate from ownership of the preview. If the user chooses another file while decoding is pending, confirm that the completed job still owns the result before changing the page. Decode success alone does not establish that this is the latest selection.

Test a deliberately invalid sample as well as a valid image. Preserve the earlier preview until the new one is ready when that behavior suits the interface. Document whether failure leaves the earlier picture visible.

Source: MDN HTMLImageElement.decode().

Handle a null callback result before naming the output. Once a Blob exists, compare its reported type with the formats your application accepts. If the application requires a particular format, show a clear failure when the result differs instead of presenting the requested extension as confirmation.

Keep the requested type and the reported type separate in diagnostic notes. This makes a fallback visible when investigating a rejected upload. Do not treat a renamed extension as a conversion of the image data.

Open a generated sample in the destination that will receive the files before running a whole batch. An accepted type still needs to meet the destination's other requirements, including any dimensions or file size limits stated by that destination.

Reference: MDN toBlob()

Published by Morphio as part of our practical image workflow notes.

Capture a sequence value at job start and compare it with the active value when asynchronous work finishes. An older job should leave the panel alone once a newer job owns it.

Apply the same ownership check to errors and progress messages. This only controls which job can update the interface; it does not cancel earlier work or release its resources. Define those cleanup steps separately.

function takeSelection(input) {
  const files = Array.from(input.files ?? []);
  if (files.length === 0) return [];
  return files;
}

This copies references into an array. It does not duplicate the bytes, validate the images or preserve files in permanent storage.

Pass that array to the job you start. Decide separately whether a later selection replaces the active job or creates another one. Reading the current input again at each processing step can make that policy unclear.

Keep output records paired with the accepted list. If the user selects more files while work is running, label them as another selection rather than silently mixing them into the earlier batch.

I work on Morphio, an image conversion project. This is a proposed way to define batch ownership. It does not describe the project's current implementation.

Reference: MDN FileList

Blob.size gives the number of bytes. Derive the budget from the destination's documented limit and make the unit conversion explicit.

function checkBudget(blob, maxBytes) {
  if (blob === null) throw new Error("No encoded image was returned");
  if (!Number.isSafeInteger(maxBytes) || maxBytes < 1) {
    throw new RangeError("The byte budget must be a positive integer");
  }
  if (blob.size > maxBytes) {
    throw new RangeError("Encoded image exceeds the byte budget");
  }
  return blob;
}

The input is an actual Blob, or null if the encoder reports failure that way. A passing result returns the same Blob. This helper checks size; it does not perform compression.

For example, 500000 as the budget means 500000 bytes. That is an illustrative number, not a stated limit for an upload service. Check what the destination means by the units it displays before converting its limit.

If the output is too large, report that and let the user revise the settings. Keep the source file so another export can start from it. Measure the replacement Blob too, since the previous result's size does not establish the new one's size.

A size check does not cover the destination's other file requirements. An image within the byte limit can still be rejected for another reason.

Reference: MDN Blob.size

toBlob() supplies its result through a callback. This wrapper turns a missing result into a rejection:

function exportPng(canvas) {
  return new Promise((resolve, reject) => {
    canvas.toBlob(blob => {
      if (blob) resolve(blob);
      else reject(new Error("Canvas encoding returned no image"));
    }, "image/png");
  });
}

async function prepareExport(canvas, report) {
  try {
    const blob = await exportPng(canvas);
    report({ state: "ready", bytes: blob.size });
    return blob;
  } catch (error) {
    report({ state: "failed", message: String(error) });
    return null;
  }
}

A synchronous exception thrown inside the Promise executor also rejects that Promise. The surrounding catch can therefore receive a synchronous toBlob() exception as well as the explicit rejection for a null callback result. It does not catch errors from unrelated work started elsewhere.

The example assumes report is a small UI update function that does not throw. Let the caller decide what to do with a null return before enabling download or upload controls.

I work on Morphio. In image export examples, I keep “requested,” “ready,” and “failed” states separate and update them as the export progresses.

Reference: MDN toBlob()

forEach does not wait for promises returned by its callback. Writing await in front of forEach does not change that, because forEach itself returns undefined.

For deliberately sequential work, use a loop and await each operation. The function below accepts the export operation as a dependency; it does not decode or encode any images itself.

async function exportInOrder(selectedFiles, exportFile) {
  const files = Array.from(selectedFiles);
  const results = [];
  for (const file of files) {
    const output = await exportFile(file);
    results.push({ name: file.name, output });
  }
  return results;
}

Await exportInOrder before showing that the whole batch succeeded. This version stops on the first thrown error or rejected promise. Handle that rejection in the caller, and decide whether a retry should restart the batch or resume from a saved result.

Sequential processing also means the next call begins only after the previous one settles. It does not automatically release memory held by the export function or by the results array. If output objects are large, decide how long the interface should keep them.

A parallel implementation needs a different completion strategy and a deliberate concurrency limit. Choose a loop that matches the order and failure behavior promised by the interface.

Reference: MDN

Promise.allSettled() is useful when each task can succeed independently. Its result array follows input order, even when the tasks finish in another order. That lets you pair each outcome with the original file without relying on completion timing.

Copy the input list before starting. Later outcomes must be paired with that same snapshot. If the user changes the selection during processing, a newer list may attach a result to the wrong filename.

The example accepts processFile as a dependency. It does not implement a decoder or converter. Wrapping the call in a promise callback also turns a synchronous throw from that function into a rejected outcome.

Give each failed file a short, useful error message. Keep detailed diagnostics where they belong, since raw decoder exceptions may expose internal details in the interface.

This pattern starts every task in the small batch immediately. It does not limit concurrency or memory use. Large photos need a separate queue or deliberately small batches. Keep successful results available for download while offering a retry only for failed files. A failure count should come from these settled outcomes, not from how many progress callbacks happened to run.

async function settleImageBatch(selectedFiles, processFile) {
  const files = Array.from(selectedFiles);
  const results = await Promise.allSettled(
    files.map(file => Promise.resolve().then(() => processFile(file)))
  );
  return results.map((result, index) => ({
    file: files[index],
    ...result
  }));
}

Reference: MDN Promise.allSettled()

I work on Morphio, a HEIC conversion project. The workflow advice here concerns preparing and checking image files.

Inspect currentSrc on the image element to see the selected resource's full URL. This helps identify the file behind a soft-looking card or an unexpectedly large download. Read it after the browser has selected a resource.

Separate the candidate list from the result

The srcset attribute describes available resources. With width descriptors, sizes describes the expected image slot under different layout conditions. These values help the browser choose a candidate; they do not give you a reliable log of what it actually chose on a particular device.

Consider a hypothetical card displayed in a narrow column on a desktop page. The source markup might list several widths. If sizes describes the card as spanning the full viewport, it gives the browser a misleading estimate of the slot. A large candidate can be reasonable for that estimate even when the rendered card is much narrower.

Record the card's rendered width, viewport width, and device pixel ratio beside currentSrc. Those details let someone else reproduce the selection. The URL alone leaves out the conditions that made a particular candidate useful.

A selected URL does not prove a successful load

A resource URL can be selected even when the resource fails to load. currentSrc identifies the choice; it does not certify that the response contained a usable image. Check the rendered result and the browser's network information when investigating a broken picture.

Avoid treating the complete property as a success flag on its own. It can be true for a broken image as well as a finished one. A decoding check or the element's error handling provides information that a selected URL cannot supply. Keep those checks separate so an error report says what actually failed.

If the page uses a picture element, inspect its source elements too. Media conditions and supported types can change the applicable candidate set. The fallback img still provides the element whose currentSrc you inspect, but looking only at its srcset may miss the relevant source declaration.

Change one condition at a time

Begin with a known viewport and a fresh load, then change the width and inspect the selection again. A smaller window need not make the browser immediately replace an image already downloaded. Resource selection can reuse what is available.

A useful comparison records the selected URL, the card's displayed width, and whether the picture looks acceptable at that width. Also check the candidate files themselves. Two filenames that suggest different widths may point to incorrectly generated copies, so markup inspection alone cannot validate the asset pipeline.

When the wrong file is selected, correct the candidate descriptors or the slot estimate that led to the choice. When the correct file still looks poor, inspect that export's dimensions and content. currentSrc helps locate the file under examination; it does not tell you which compression setting to use. Save those observations with the layout conditions before changing the image exports.

Width, quality, and composition can each change during export. Pixel dimensions describe the sample grid. JPEG quality influences how the encoder represents that grid. Cropping decides which part of the scene remains. You can make a file smaller through any of these choices, with different consequences for the finished picture.

Write down the destination first

Imagine a photograph that will appear in a 900-pixel-wide article column. A 600-pixel-wide export has fewer horizontal samples than that display width. Enlarging it may reveal softness. A 3000-pixel-wide export contains more samples, but may carry more data than this particular placement needs.

Those figures are a worked example, not a universal export recommendation. A publication may provide a larger source for high-density displays or allow readers to open the original. Use the destination's actual requirements rather than copying a width from another website.

Start by recording what the upload form requires and what the page displays. Keep those two requirements separate. A form may accept a much larger image than its layout needs, and an accepted upload may still be cropped after submission.

Compare two changes separately

Take one source copy and make two experimental exports. For the first, keep the pixel dimensions unchanged and lower the JPEG quality setting. For the second, keep a chosen quality setting and reduce the dimensions. Give the files names that identify the change so that the comparison remains readable later.

Open both results at the size readers will see. Then inspect a detail that matters to the photograph. A face, a product label, or fine branches can reveal different problems. Reduced dimensions remove spatial samples. Stronger JPEG compression can add visible artifacts even when the width and height remain unchanged.

Avoid reading the quality slider as a promised percentage reduction in bytes. Encoders and source images differ. A setting of 0.8 does not mean that the result will contain 80 percent of the source file's bytes, or retain a measurable 80 percent of its visual quality.

Save the reason for choosing this file

Record the destination dimensions, file bytes, and the visible reason for choosing one export. A short note such as "label readable at article width" gives the decision more context than "smallest file." If neither sample works, adjust the export and inspect again rather than accepting the lower byte count by default.

I work on Morphio, which focuses on image conversion. The useful handoff from a conversion workflow is a file that fits its intended use, with an original still available if the destination changes. The chosen file needs enough detail for the intended placement while meeting its transfer requirements.

Keep the source outside the experiment folder and avoid repeated JPEG saves of the same working copy. When you need another comparison, return to that source. This makes it easier to tell whether the new settings helped, rather than comparing two files with different histories of editing and compression.

Reference: MDN's image format guide.

Browsers place separate restrictions on reading a remote image through a canvas. When an image from another origin is drawn without the required CORS permission, the canvas becomes tainted. MDN explains the restrictions in its cross-origin image guide.

Check the request and the response

For a public image that does not need credentials, an application can request it in anonymous CORS mode:

const image = new Image();
image.crossOrigin = "anonymous";
image.src = imageUrl;
await image.decode();

Set crossOrigin before assigning src. The image server must also return an appropriate Access-Control-Allow-Origin header. Changing the JavaScript alone does not grant access to a server that has not permitted it.

If the server allows ordinary embedding but does not allow CORS access, this modified request can fail to load. Record that load failure: the application requested CORS access, and the server did not provide the response needed for it.

Keep the experiment small

Start with a new canvas and draw one image. Try the export immediately. Do not include a remote watermark, background texture, or another source yet. Otherwise, a permitted photograph can be blamed for a restriction introduced by a different image drawn later.

Compare that result with a same-origin test asset. If the same export function works for the local asset but fails after drawing the remote image, inspect the remote request in the browser's network panel. Record the final resource URL and response headers. A redirect can make the final origin different from the one suggested by the URL initially supplied to the application.

Do not try to repair the situation by changing a .png suffix to .jpg, lowering quality, or using a different canvas export method. Those changes do not supply the missing permission. A production error message should explain which source could not be exported, rather than reporting that the image format is unsupported.

Decide which sources the feature supports

If users supply their own files through a file picker, keep that workflow separate from the feature that imports arbitrary remote URLs. They have different failure cases. A conversion interface that mixes both paths behind one generic error makes troubleshooting unnecessarily difficult.

If the application controls the remote server, configure and test its CORS response for the intended callers. If it does not control that server, offer an authorized file-upload path or state that the particular URL cannot be exported. A server-side import feature needs an explicit design for access and resource limits. Keep that decision separate from the browser example.

For a bug report, a useful record includes the source origin, request mode, returned CORS header, and the operation that failed. The fact that the image was visible belongs in that report too, but visibility alone does not establish permission to export the canvas.

Keep this record with the failing example. The next person investigating the export can compare the request and response directly, without first having to reproduce every step of the larger editor interface.

Help people choose a suitable file with the picker filter, then check the selected input and explain any failure where it appears. A file that exceeds a stated byte limit needs a different message from a file that cannot be decoded.

Give the filter a specific purpose

Match the filter to formats your receiving workflow actually handles. Advertising a broad image category can leave people uncertain about why a photo selected from their library later fails. State the supported types beside the input too, where someone can read them before opening the picker.

A browser preview is useful feedback. It should have its own failure state and should not be described as proof that a server will accept the file. The preview and receiver may use different processing paths. A successful local display does not replace the checks required by the receiving service.

I work on Morphio, which has HEIC conversion tools. When an upload destination specifically needs JPEG, conversion can prepare a compatible copy of an HEIC photograph. Keep that advice separate from the upload control's validation: a link to a converter cannot establish that every returned file satisfies the receiver's rules.

Test messages with distinct inputs

Prepare a small set of files with known purposes. Include an allowed image, an image exceeding the form's stated limit, and an input the preview cannot decode. Check that the interface explains each outcome without discarding a previously valid selection unexpectedly.

Also inspect the path after an upload is rejected by the receiver. Preserve enough context for the user to correct the file. If the receiver reports a size limit, show the unit and whether the limit concerns a single file or the whole request.

Keep server-side validation even when the interface looks restrictive. The receiver must decide what it can process and store after the picker has helped someone choose an input. Document those responsibilities where future changes to the form will be made, so a cleaner picker is not mistaken for permission to remove receiving checks.

Reference: MDN's accept attribute documentation.

Consider a 4000 by 3000 photograph placed in a 300 by 300 pixel image element. The source ratio is 4:3 and the element is square. The layout needs a rule for fitting those different ratios.

Work through the two scale factors

To fit the full width into the square, the scale factor is 300 divided by 4000, or 0.075. That produces a displayed image 300 pixels wide and 225 pixels tall. Seventy-five pixels of the square's height remain unfilled.

To fill the full height, the factor is 300 divided by 3000, or 0.1. The displayed image becomes 400 pixels wide and 300 pixels tall. One hundred pixels of its width extend beyond the square. With centered positioning, the visible area excludes 50 displayed pixels on each side.

These calculations describe this example's display size. The downloaded file keeps its own dimensions and byte count.

Choose the behavior the card needs

.photo {
  width: 300px;
  height: 300px;
  object-fit: cover;
  object-position: 50% 50%;
}

Cover preserves the source aspect ratio while filling the element. Parts that do not fit are clipped. Contain preserves the full image within the element and can leave unused space. Fill can stretch the image to the element's proportions.

For a gallery that must show every edge, contain may be a useful choice. For a card whose image area must always be filled, cover may suit the design. Decide with a sample containing a subject near the border. A landscape with empty sky can conceal a crop that would damage a group portrait.

Object-position controls where the image sits within the element. A different position can improve a particular crop, but it cannot guarantee that every subject remains visible at every container ratio. Test the narrow layout as well as the desktop layout before keeping a position as a default.

Compare the card with the original

Open the original file in its own viewer and compare its full frame with the card. If the full frame is present there, changing JPEG quality will not bring the hidden edges back inside the square. Review the layout rule or create an intentional crop for that component.

CSS cropping also does not, by itself, make the downloaded file smaller. A page can hide much of a large image while transferring the entire asset. Choosing an appropriately sized delivery image is another part of the publishing workflow.

For a practical review, prepare one wide image and one tall image with a visible border. Place each in the same card and compare cover with contain. Then move a subject toward an edge and test the responsive layouts. Keep the full source so that a future card design can use a different crop.

References: MDN's object-fit and object-position documentation.

After exporting, check its pixel dimensions and its size in bytes. They describe different things. A preview that fits neatly on your screen tells you little about either measurement.

Take a 4000-by-3000 photo and export it at 2000 by 1500. You now have a quarter as many pixels. You cannot infer that the file is a quarter as large, because its format, the picture's content, and the encoder settings also affect the byte count.

JPEG usually uses lossy compression. Reducing its quality setting can make the file smaller while losing detail. PNG compresses without that loss, but a PNG version of a photo may be larger than a JPEG. Check the form's accepted formats before spending time on a different export.

I would write down the destination's limits before changing anything. A form may require a minimum width as well as a maximum file size. Export one copy that meets the dimensions, check its actual byte count, then open it at the size readers will see. If the photo contains text, check that you can still read it.

An iPhone HEIC photo may need conversion to JPEG for the receiving site. I work on Morphio's HEIC-to-JPG tool. A converted copy still needs the same measurements; changing formats does not guarantee it will fit a particular upload limit.

Keep the source photo while trying settings. If the smaller copy loses too much detail, return to the source for another export instead of repeatedly saving the compressed JPEG. Once the form accepts a copy that looks right, keep its settings with it so you can prepare the next photos the same way.

Reference: MDN's image format guide.

Many JPEG encoders handle brightness and color detail separately. They can keep the brightness information at full resolution while storing less detail for color. This is called chroma subsampling. With the common 4:2:0 arrangement, a two-by-two group of pixels has separate brightness samples but shares lower-resolution color information. When the file is opened, the decoder estimates the color between those stored samples.

In a photograph, neighboring pixels often have similar colors, so that shortcut may be hard to see. Thin colored text is less forgiving. Its color can jump abruptly at an edge, and reduced color resolution can make that edge look smeared even if the brightness boundary is still clear.

A fuzzy JPEG edge is not proof of chroma subsampling. JPEG quantization can soften edges too. If your encoder exposes a subsampling setting, export one small crop twice with the same quality setting: once at 4:2:0 and once at 4:4:4. View both at 100%. The 4:4:4 copy keeps full chroma resolution, though it may take more space and is still a lossy JPEG.

This matters most when the image has small type, interface elements, or hard color boundaries. For a UI screenshot or diagram, also make a PNG copy and compare the text at the size people will actually see it. A photograph can tolerate a different trade-off from a line of colored text.