3 ms·

The original entrant in this competition is TIFF, and—like Matroska or QuickTime add indexing to raw MP3 or MPEG-TS—it does provide useful functionality over ra

The original entrant in this competition is TIFF, and—like Matroska or QuickTime add indexing to raw MP3 or MPEG-TS—it does provide useful functionality over raw codec stream non-formats like JPEG (properly JIF/JFIF/EXIF), in the form of striping or tiling and ready-made downscaled versions for the same image. But where unindexed video is essentially unworkable, an untiled image is in most cases OK, except for a couple of narrow application areas that need to deal with humongous amounts of pixel data. So you’re absolutely going to see TIFF containers with JPEG or JPEG2000 tiles used for geospatial, medical, or hi-res scanned images, but given the sad state of open tooling for all of these, there’s little to no compatibility between their various subsets of the TIFF spec, especially across vendors, and more or less no FOSS beyond libtiff. (Not even viewers for larger-than-RAM images!) Some other people have used TIFF but in places where’s very little to be gained from compatibility (e.g. Canon’s CR2 raw images are TIFF-based, but nobody cares). LogLuv TIFF is a viable HDR format, but it’s in an awkward place between the hobby-renderer-friendly Radiance HDR, the Pixar-backed OpenEXR, and whatever consumer photo thing each of the major vendors is pushing this month; it also doesn’t have a bit-level spec so much as a couple of journal articles and some code in libtiff. Why did this happen? Aside from the niche character of very large images, Adobe has abandoned the TIFF spec fairly quickly after it acquired it as part of Aldus, but IIUC for the first decade or so of that neglect Adobe legal was nevertheless fairly proactive about shutting up anyone who used the trademarked name for an incompatible extension (like TIFF64—and nowadays if you need TIFF you likely have >2G of data). Admittedly TIFF is also an overly flexible mess, but then so are Matroska (thus the need for the WebM profile of it) and QuickTime/BMFF (thus 3GPP, MOV, MP4, ..., which are vaguely speaking all subsets of the same thing). One way or another, TIFF is to some extent what you want, but it doesn’t get a lot of use these days. No browser support either, which is likely important. Maybe the HEIF container (yet another QuickTime/BMFF profile) is better from a technical standpoint, but the transitive closure of the relevant ISO specs likely comes at $10k or more. So it’s a bit sad all around.

mcpackieh 3y ago
> Admittedly TIFF is also an overly flexible mess, but then so are Matroska (thus the need for the WebM profile of it) Webm went way too far when they stripped out support for subtitles. The engineers who made that decision should be ashamed.
- mananaysiempre 3y ago
  As much as I’m fond of my collection of Matroska files with SSA/ASS subtitle tracks, I don’t think those are appropriate for the Web, what with all the font issues; and SRT is a nightmare of encodings. But apparently there’s a WebM-blessed way[1] of embedding WebVTT ( = SRT + UTF-8 − decimal commas) now? Which is of course different[2] from the more recent Matroska.org-blessed way[3], sigh. [1] https://www.webmproject.org/docs/container/#webvtt-guidelines https://www.webmproject.org/docs/container/#webvtt-guideline... [2] https://trac.ffmpeg.org/ticket/5641 https://trac.ffmpeg.org/ticket/5641 [3] https://matroska.org/technical/codec_specs.html#s_textwebvtt https://matroska.org/technical/codec_specs.html#s_textwebvtt
  - Lammy 3y ago
    > I don’t think those are appropriate for the Web, what with all the font issues Fun fact: several broadcast standards use Bitstream TrueDoc Portable Font Resource, which was supported for embedded web fonts way back in Netscape 4: https://people.apache.org/~jim/NewArchitect/webrevu/1997/11_07/webauthors/11_07_97_2.html https://people.apache.org/~jim/NewArchitect/webrevu/1997/11_... https://web.archive.org/web/20040407162455/http://www.bitstream.com/categories/developer/truedoc/pfrspec.html https://web.archive.org/web/20040407162455/http://www.bitstr... “The PFR specification defines the Bitstream portable font resource (PFR), which is a compact, platform-independent format for representing high-quality, scalable outline fonts. Many independent organizations responsible for setting digital TV standards have adopted the PFR font format as their standard font format, including: — ATSC (Advanced Television Systems Committee) — DAVIC (Digital Audio Visual Council) — DVB (Digital Video Broadcasting) — DTG (Digital TV Group) — MHP (Multimedia Home Platform) — ISO/IEC 16500-6:1999 — OCAP (OpenCable Application Platform)”
  - gsich 3y ago
    All text based subtitles share the (non-)issue of encoding. Nothing wrong with SRT, it's UTF8 in Mkv anyway.
omoikane 3y ago
I think TIFF has some unique features that makes it more prone to certain security issues[1] compared to other formats, such as storing absolute file offsets instead of relative offsets. So I am not sure TIFF is a good container format, but many camera raws are TIFF-based for some reason.[2] [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtiff https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtiff [2] https://exiftool.org/#supported https://exiftool.org/#supported (search for "TIFF-based")
- mananaysiempre 3y ago
  > I think TIFF has some unique features that makes it more prone to certain security issues[] compared to other formats, such as storing absolute file offsets instead of relative offsets. That’s an impressive number of CVEs for a fairly modest piece of code, although the sheer number of them dated ≥ 2022 baffles me—has a high-profile target started using libtiff recently, or has some hero set up a fuzzer? In any case libtiff is surprisingly nice to use but very old and not that carefully coded, so I’m not shocked. I’m not sure about the absolute offsets, though. In which respect are those more error-prone? If I was coding a TIFF library in C against ISO or POSIX APIs—and without overflow-detecting arithmetic from GCC or C23—I’d probably prefer to deal with absolute offsets rather than relative ones, just to avoid an extra potentially-overflowing addition whenever I needed an absolute offset for some reason. There are things I dislike about TIFF, including security-relevant ones. (Perhaps, for example, it’d be better to use a sequential format with some offsets on top, and not TIFF’s sea of offsets with hopefully some sequencing to them. Possibly ISO BMFF is in fact better here; I wouldn’t know, because—well—ISO.) But I don’t understand this particular charge.
  - omoikane 3y ago
    Absolute file offsets demand a particular memory layout or some extra bookkeeping that could be avoided with relative offsets. If I were to write a JPEG parser, I could write a function to handle one particular segment and not have to worry about other segments because relative offsets makes parsing them independent, compared to TIFF where I need to maintain a directory of things and make sure the offsets land in the right place. I think parsing file format with absolute offsets is similar to handling a programming language with all GOTOs, compared to relative offsets which are more like structured control flow.

mcpackieh 3y ago

> Admittedly TIFF is also an overly flexible mess, but then so are Matroska (thus the need for the WebM profile of it) Webm went way too far when they stripped out support for subtitles. The engineers who made that decision should be ashamed.

mananaysiempre 3y ago
As much as I’m fond of my collection of Matroska files with SSA/ASS subtitle tracks, I don’t think those are appropriate for the Web, what with all the font issues; and SRT is a nightmare of encodings. But apparently there’s a WebM-blessed way[1] of embedding WebVTT ( = SRT + UTF-8 − decimal commas) now? Which is of course different[2] from the more recent Matroska.org-blessed way[3], sigh. [1] https://www.webmproject.org/docs/container/#webvtt-guidelines https://www.webmproject.org/docs/container/#webvtt-guideline... [2] https://trac.ffmpeg.org/ticket/5641 https://trac.ffmpeg.org/ticket/5641 [3] https://matroska.org/technical/codec_specs.html#s_textwebvtt https://matroska.org/technical/codec_specs.html#s_textwebvtt
- Lammy 3y ago
  > I don’t think those are appropriate for the Web, what with all the font issues Fun fact: several broadcast standards use Bitstream TrueDoc Portable Font Resource, which was supported for embedded web fonts way back in Netscape 4: https://people.apache.org/~jim/NewArchitect/webrevu/1997/11_07/webauthors/11_07_97_2.html https://people.apache.org/~jim/NewArchitect/webrevu/1997/11_... https://web.archive.org/web/20040407162455/http://www.bitstream.com/categories/developer/truedoc/pfrspec.html https://web.archive.org/web/20040407162455/http://www.bitstr... “The PFR specification defines the Bitstream portable font resource (PFR), which is a compact, platform-independent format for representing high-quality, scalable outline fonts. Many independent organizations responsible for setting digital TV standards have adopted the PFR font format as their standard font format, including: — ATSC (Advanced Television Systems Committee) — DAVIC (Digital Audio Visual Council) — DVB (Digital Video Broadcasting) — DTG (Digital TV Group) — MHP (Multimedia Home Platform) — ISO/IEC 16500-6:1999 — OCAP (OpenCable Application Platform)”
- gsich 3y ago
  All text based subtitles share the (non-)issue of encoding. Nothing wrong with SRT, it's UTF8 in Mkv anyway.

omoikane 3y ago

I think TIFF has some unique features that makes it more prone to certain security issues[1] compared to other formats, such as storing absolute file offsets instead of relative offsets. So I am not sure TIFF is a good container format, but many camera raws are TIFF-based for some reason.[2] [1] https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtiff https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=libtiff [2] https://exiftool.org/#supported https://exiftool.org/#supported (search for "TIFF-based")

mananaysiempre 3y ago
> I think TIFF has some unique features that makes it more prone to certain security issues[] compared to other formats, such as storing absolute file offsets instead of relative offsets. That’s an impressive number of CVEs for a fairly modest piece of code, although the sheer number of them dated ≥ 2022 baffles me—has a high-profile target started using libtiff recently, or has some hero set up a fuzzer? In any case libtiff is surprisingly nice to use but very old and not that carefully coded, so I’m not shocked. I’m not sure about the absolute offsets, though. In which respect are those more error-prone? If I was coding a TIFF library in C against ISO or POSIX APIs—and without overflow-detecting arithmetic from GCC or C23—I’d probably prefer to deal with absolute offsets rather than relative ones, just to avoid an extra potentially-overflowing addition whenever I needed an absolute offset for some reason. There are things I dislike about TIFF, including security-relevant ones. (Perhaps, for example, it’d be better to use a sequential format with some offsets on top, and not TIFF’s sea of offsets with hopefully some sequencing to them. Possibly ISO BMFF is in fact better here; I wouldn’t know, because—well—ISO.) But I don’t understand this particular charge.
- omoikane 3y ago
  Absolute file offsets demand a particular memory layout or some extra bookkeeping that could be avoided with relative offsets. If I were to write a JPEG parser, I could write a function to handle one particular segment and not have to worry about other segments because relative offsets makes parsing them independent, compared to TIFF where I need to maintain a directory of things and make sure the offsets land in the right place. I think parsing file format with absolute offsets is similar to handling a programming language with all GOTOs, compared to relative offsets which are more like structured control flow.