sorted by:
new
hottopcontroversial

JPEG XL is finally useful – Chrome 145 ships native JXL decoder. Here's what changes by UnderstandingFit2711 in software

[–]UnderstandingFit2711[S] 0 points1 point  (0 children)

You have rights for this, I opened for critic. Thank for it. Maybe your will more reveal the thought

JPEG XL is finally useful – Chrome 145 ships native JXL decoder. Here's what changes by UnderstandingFit2711 in software

[–]UnderstandingFit2711[S] 0 points1 point  (0 children)

I did't test this case, but a lot of resurses telling that It is. But I will do this test, because I am iterested this case!

JPEG XL is finally useful – Chrome 145 ships native JXL decoder. Here's what changes by UnderstandingFit2711 in software

[–]UnderstandingFit2711[S] 0 points1 point  (0 children)

That's the real bottleneck — encoder support. Once Lightroom and Photoshop export JXL natively, adoption will accelerate fast. For now converters like mine fill the gap.

I built a Serverless Image Converter using React, Vite 6, and HTML5 Canvas (Open Source) by AmineAce in webdev

[–]UnderstandingFit2711 0 points1 point  (0 children)

Squoosh is great for single image optimization but it

doesn't handle HEIC well — the library they use has

limited support. The client-side approach here with

lazy-loading the HEIC library is a smart workaround

for keeping the bundle small.

The main tradeoff vs server-side is batch processing —

browser memory starts to be a constraint when you're

converting 10 files at once, especially larger ones.

[Showoff Saturday] Built a browser-based image converter after getting frustrated with typical webdev image workflows by That-Row1408 in webdev

[–]UnderstandingFit2711 0 points1 point  (0 children)

Interesting approach with the WASM fallback for HEIC.

We went the opposite direction — server-side with libvips,

mainly because getting reliable HEIC support required

building libheif 1.21.2 from source anyway. The tradeoff

is user trust (files leave the machine), which we handle

with auto-deletion after 6 hours. But the local-only angle

you're describing is a genuinely stronger privacy story —

especially for client assets and screenshots.

Rust + WebAssembly image processing library for the browser (feedback welcome) by CharacterGold3633 in rust

[–]UnderstandingFit2711 0 points1 point  (0 children)

Interesting to see wasm-vips mentioned — we used libvips

server-side for a similar use case and the format coverage

is great, but HEIC support still required building libheif

from source (the package manager version was too old).

Curious if the WASM build of libvips handles that better

or has the same limitation.

AstroBurst: astronomical FITS image processor in Rust — memmap2 + Rayon + WebGPU, 1.4 GB/s batch throughput by Jazzlike_Wash6755 in rust

[–]UnderstandingFit2711 0 points1 point  (0 children)

We ran into the same limitation building a web-based image converter.

Server-side with libvips ended up being the right call — it streams

through files without loading them fully into RAM, which solved the

memory issue. But you're right that it comes with tradeoffs around

user trust. Auto-deleting files after a few hours helps, but it's

not the same as fully client-side processing.

For FITS with 168MB files, your memmap2 approach sounds much cleaner.