Gregory's ServerTIL that JPEG encoding in the wild is even more complicated than the very complicated documentation makes it out to be. For example, most references I can find say that the difference between an RGB and a CMYK jpeg is the former will have 3 "components" and the latter 4. This in theory should be encoded in a particular start-of-frame byte. And yet I have seen images detected as CMYK by ffmpeg have "03" in that byte position. And there are reports of CMYK jpegs that are really RGB under the hood?
 9 comments
The other thing I learned today is I truly love when my job requires me to bust out a hex editor to inspect file encodings  @aparrish all I want is to manually count offsets and go "oh that's A7 and I was expecting A6! Interesting...."    @darius The most fun I had working on HTML5 (in the most tiny of roles, btw) was when people would bring stuff like this to the working group and I'd get to go dive into the archives of the internet trying to reverse engineer the decision making that led us to the state we were in. 99% of the time there was never ill intent - some implementation was left with a bunch of bad choices and the people responsible picked the one they thought would cause the least harm.  @darius I've never read the JPEG spec. Still about 18 years ago I tried to get a CMYK JPEG into a more easily usable format. I wrote up my adventures in learning about the format here: |
@darius If so, that'd be super annoying. We sorta rely on CMYK jpegs for printing...