MediaArea
JPEG: fix detection of PhotoYCC and PhotoYCC-A/ fix detection of CMYK with APP14 set to 0
Sample for the CMYK case is here:
JPEG APP14 (12 bytes):
+ [BinaryData directory, 7 bytes]
| DCTEncodeVersion = 100
| APP14Flags0 = 0
| APP14Flags1 = 0
| ColorTransform = 0
Does RGB need the same fix as here for APP14 0? Looks like no...
https://github.com/mozilla/mozjpeg/issues/267#issue-260903131
@JeromeMartinez
Even with my patch these samples are still recognized as YUVA, not as YCCK. Sigh. https://trac.ffmpeg.org/ticket/4686?replyto=1#comment
It was ans still is an headache... And maybe even worse while checking your comments, because " these samples are still recognized as YUVA, not as YCCK" has a link on YUVA files and this patch changes that.
Let's try to summarize:
- we want to keep "YUV" for all names from the YUV / YU'V' / YCC / YCbCr.
- PhotoYCC was a mistake, it looks like YUV with specific transform, so at some point I wish to change the output.
- fo you have files with PhotoYCC / PhotoYCC-A content?
- issue is that the magic value in APP14 is not "Adobe\0" but "Adobed". Why "d?" No idea... while adding "Adobed", it is OK. I'll tweak the patch.
I think that implementing same algo as Java may be good https://docs.oracle.com/javase/1.5.0/docs/api/javax/imageio/metadata/doc-files/jpeg_metadata.html#color
has a link on YUVA files and this patch changes that.
Oh, it does? Then I am sorry. Those files are indeed YCCK and if this patch fixes it it is great. I did not test it propely, sorry.
- PhotoYCC was a mistake
No, it was not. PhotoYCC was the colorspace used in PhotoCD and in FlashFix, FlashPix also uses NIF RGB that was some time later renamed into sRGB :) PhotoYCC has different quantisation, uses nonscaled BT.601 matrix and also uses after that very strange scalers and xvYCC transfer... After that the primaries are BT.709 except negative RGB can be outside of it, just like in xvYCC and superwhite is not clamped. Also different viewing environment from sRGB.
- fo you have files with PhotoYCC / PhotoYCC-A content?
How would I know? Everybody uses Mediainfo to check for that. I have a crazy amount of .PCD files though on archive.org for example that all use PhotoYCC and to preserve them in JPEG you have to tag them as PhotoYCC.
You can start with Kodak sampler https://www.math.purdue.edu/~lucier/PHOTO_CD/IMAGES/ and latest ffplay :) and continue with those from Corel. https://archive.org/search.php?query=Kodak+pcd I suppose you can try to find such JPEGs somewhere there too. D:) FFplay does not color manage them correcly though.
- issue is that the magic value in APP14 is not "Adobe\0" but "Adobed".
I was not able to find the inverted K samples with any changes like that, because in PDF inverted K is actually signalled differently. It is an actual bug in pdfimages, but thanks to that bug I was able to extract such a file "losslessly": https://gitlab.freedesktop.org/cairo/cairo/-/issues/156#note_857848 (that is from Lewin's Cells on Libgen).
think that implementing same algo as Java may be good
It does implement it.
I found how the inverted K is signalled: https://bugzilla.mozilla.org/show_bug.cgi?id=674619#c7
APP12 'EMBED\x00' (in hex: FF EC 00 08 45 4D 42 45 44 00)
https://wiki.mozilla.org/PDF.js/EMBED