Project ideas from Hacker News discussions.

The case against JPEG XL

📝 Discussion Summary (Click to expand)

1. Debate over the usefulness of lossless images on the web
- Pro‑lossless: “I'm active in many art communities on the web for whom being able to view and share lossless images are table stakes.” – SmasherEpilepti
- Anti‑lossless: “Lossless was discounted because lossless just isn't very useful on the Web.” – computerbuster

2. Trade‑off between file‑size savings and decoding time
- “Well it obviously depends on the connection, but at 3g speeds and higher, the decoding time outweighs the fairly minor bandwidth saving.” – jaffathecake
- “I save 21 kB, but pay 23 ms.” – jaffathecake

3. Browser support as a catalyst for broader adoption
- “I would argue that even if JPEG XL isn't the best choice for Web images, if browsers don't support it then that will widely hinder its adoption for its non‑Web use cases.” – rmunn
- “Both Firefox and Chrome have committed to shipping JPEG XL later this year. Safari has supported JPEG XL since 2023…” – alwillis

4. Strong non‑web use cases for JPEG XL (photography, RAW, medical, 3D, etc.)
- “I think it is a potentially good camera format, good medical & scientific imaging format, good RAW compression format (Apple uses it in some newer iPhones for this), good media interchange formats for tools like Photoshop…” – computerbuster
- “It's a great option for 3D art texturing and compositing. I could see using it over OpenEXR…” – SmasherEpilepti

5. Technical concerns: complexity, progressive rendering, hardware limits
- “A potentially major issue I have with AVIF is that because it is based on a video format, any hardware decoding support AVIF will get is likely to be restrained to common video scenarios… only 4:2:0 YUV being supported by hardware decoders.” – Daiz
- “I prefer the UX of the AVIF example here… a progressive phase where the image is obviously 'not ready', yet you can still determine important details…” – jaffathecake (regarding progressive rendering differences)


🚀 Project Ideas

JPEG XL Lossless Recompressor

Summary

  • Desktop CLI/GUI tool that losslessly converts JPEG/JPEG XL files to JPEG XL, reducing storage by ~20% without quality loss.
  • Enables batch processing of personal photo libraries, backups, and archives.

Details

Key Value
Target Audience Photographers, archivists, hobbyists with large JPEG collections
Core Feature Lossless JPEG → JPEG XL transcoding (and optional reverse) with verification
Tech Stack Rust (libjxl bindings), Tauri for GUI, CLI via clap
Difficulty Medium
Monetization Hobby

Notes

  • HN users like rmunn praised lossless JPEG→JPEG XL as a "killer app" for storage savings. - Provides concrete tool for the non‑web use case that drives adoption.

Progressive Image Preview Library

Summary

  • Small JS library that loads images using JPEG XL progressive decoding (or falls back to AVIF/WebP) and shows a useful low‑resolution preview that retains salient details, not just a blurhash.
  • Improves perceived performance on slow connections.

Details

Key Value
Target Audience Front‑end developers, web performance engineers
Core Feature Progressive image component with configurable preview quality and saliency‑based rendering
Tech Stack TypeScript, WebAssembly JPEG XL decoder (libjxl wasm), IntersectionObserver
Difficulty Medium
Monetization Hobby

Notes

  • Commenters like F3nd0 and jaffathecake debated progressive UX; a library that gives a clear preview would be welcomed. - Could be discussed in HN threads about image loading techniques.

JPEG XL Browser Polyfill (Wasm)

Summary

  • WebAssembly module that decodes JPEG XL images and paints them into or replaces src via srcset, enabling JPEG XL support in browsers without native implementation.
  • Includes fallback to native formats when available.

Details

Key Value
Target Audience Web developers, site owners wanting to serve JPEG XL today
Core Feature Drop‑in polyfill that auto‑detects elements with .jxl and decodes them
Tech Stack Rust → wasm (libjxl), tiny wrapper script, optional Service Worker integration
Difficulty High
Monetization Hobby

Notes

  • rmunn argued that lack of browser support hinders camera adoption; a polyfill would let sites start using JPEG XL now. - HN discussion highlighted desire for universal support; polyfill addresses that directly.

Smart Image CDN with Content‑Aware Format Selection

Summary

  • API/CDN service that receives an original image, analyzes its content (e.g., text, line art, photographs, HDR) and client capabilities (browser Accept, hardware decode, connection) then returns the optimal format (AVIF, JPEG XL, WebP, PNG) with appropriate lossless/lossy settings.
  • Includes automatic lossless WebP/JPEG XL extension handling.

Details

Key Value
Target Audience SaaS platforms, e‑commerce sites, content publishers
Core Feature Content‑aware image optimization endpoint with format negotiation
Tech Stack Go/Rust backend, libvips or ImageMagick bindings, libjxl, libaom, libwebp, Fastly edge compute
Difficulty High
Monetization Revenue-ready: tiered pricing per GB processed

Notes

  • Users like Daiz complained about AVIF 4:2:0 limitation for illustrations; this service would pick JPEG XL or lossless WebP when needed. - IshKebab wanted a single format that works everywhere; the service abstracts that complexity.

Lossless WebP File Extension & Detection Tool

Summary

  • Utility that scans directories, detects lossless WebP files (via bitstream inspection), and renames them to .webpl (or adds XMP tag) so that lossless vs lossy is obvious at a glance.
  • Includes a web server module that serves .webpl with correct MIME type and fallback.

Details

Key Value
Target Audience Developers, designers, sysadmins managing WebP assets
Core Feature Lossless WebP detection and renaming + optional server plugin
Tech Stack Python (or Rust) using libwebp to inspect bitstream, watchman/fsnotify for live mode
Difficulty Low
Monetization Hobby

Notes

  • nananana9 lamented the lack of a distinct extension for lossless WebP causing confusion; this tool directly solves that pain point. - HN commenters would appreciate a simple utility to avoid guessing which WebP is lossless.

Read Later