Dear Maintainer,

Currently file behavior is as follow (on the gunzip'ed attached file):

Input files:

% file black*.j*
black.j2k:        JPEG 2000 codestream
black_jfif.jpg:   JPEG image data, JFIF standard 1.01, aspect ratio, density 1x1, segment length 16, baseline, precision 8, 512x512, components 1
black.jp2:        JPEG 2000 Part 1 (JP2)
black_noAPP0.jpg: JPEG image data, baseline, precision 8, 512x512, components 1

leads to the following mime-type behavior:

% file --mime-type black*.j*
black.j2k:        application/octet-stream
black_jfif.jpg:   image/jpeg
black.jp2:        image/jp2
black_noAPP0.jpg: image/jpeg

One can verify that removing the APP0 marker entirely does not affect
file --mime-type behavior. The mime-type reported is image/jpeg. One can
noticed that in the case of multiple components there could be an issue
since no color space information would be carried in one such file (no
APP0).

Consider now the behavior for JPEG 2000 codestream. file --mime-type
returns "application/octet-stream". This can clearly be improved. JPEG
2000 codestream while not mainstream can be found encapsulated in PDF
1.7 document. It would make sense for `file` to report in one such case:

% file --mime-type black.j2k
black.j2k:        image/jp2

The online documentation:

* https://www.iana.org/assignments/media-types/image/jp2

states:

[...]
Magic number(s):                   12 byte string: X'0000 000C 6A50 2020
                                   0D0A 870A' (for all JPEG-2000 family
                                   files)
[...]

The above is quite clear for black.jp2, but the interpretation should
not be too strict. And indeed mime-type for black.j2k should also be
'image/jp2'.

Thanks for consideration