Image file formats that didn’t make it

Should vml be included as a vector markup image format? Msft was forced to abandon vml in favor of open svg.

VRML is still used as an input format for colour 3d printing, eg. https://www.stratasysdirect.com/resources/design-guidelines/...

Geo-tiffs are the go to standard in GIS integration of any property map. Photoshop works really well with tiffs.

Most of the IFF images produced on the Amiga were also ordered by bitplanes, but that's bitplanes of an n-bit number for each pixel, referencing a colour lookup tables.

JPEG-2000 was held back by intellectual property restrictions: patents but also the fact that the spec cost $1,500. A lot of the parties involved appeared to think that the technical merits made adoption inevitable and so they didn't spend time making it appealing with things like a test suite or high-quality open source implementation.

That had several impacts which scarred a lot of people I've worked with:

1. The commercial implementations were not interoperable and people get VERY nervous when they periodically get images which won't open correctly in one tool or, worse, have defects which one tool hides.

2. Many open source tools either didn't support the format at all or used Jasper, which just didn't get enough support to be fast or compliant.

3. Performance was quite slow for a while and people who weren't starting with Photoshop or native Mac apps (ImageKit uses the Kakadu codec, which has decent performance) were probably hitting Jasper or the Java implementation, both of which were orders of magnitude slower. People will forgive a certain performance hit for better compression but, especially as network bandwidth and storage capacity went up so much, the savings just weren't worth it if you could transfer and decode a JPEG in less time than it took just to decode the JP2.

4. All of that combined to mean browsers never really implemented it, other than Safari which picked it up via the standard image framework. The complexity meant that getting acceptable performance and security would be expensive and the demand just wasn't there.

5. The complexity of the format and low encoding performance meant that many JP2s were not encoded with optimized settings, which reduced the benefits to supporting it.

This makes me a bit sad because technically it was the only format for a long time which supported a wide range of colorspaces, bit depths, etc. and the way you can progressively decode a stream would have been a really neat option for responsive images in HTML — imagine if all your srcset had to do was say “Range-request bytes 1-x for 512x512, 1-y for 1024x1024, …” and the server + CDN could host & cache a single file for every client.

There are certain scenarios where the progressive / tiled decoding can make up for the friction (medical imaging and archival storage in libraries/archives) but they're not widespread enough to establish an entire image format. The open source situation has never been better with OpenJPEG but there just doesn't seem to be a high likelihood of significant increases in demand at this point.