| • brooke |
| May 15 2009, 12:13 AM |
| F5715: jpg2000.patch |
| Nov 21 2014, 10:38 PM |
Description
Rolling this out of T13871, which was asking for _support_ for JPEG 2000 images. Since they're not widely supported by browsers and they're a lossy format without a clear benefit to use I'm WONTFIXing that for now, but the upload bug that makes it possible to mistakenly upload them remains.
http://commons.wikimedia.org/wiki/Image:VIC_2_SECTION_%28Converted%29-1.jpg
is an example of a file that was first uploaded as JPEG 2000 (the current version was correctly converted to regular JPEG).
http://test.wikipedia.org/wiki/File:A_JPEG_2000_file.jpg
is an example mentioned also on the previous bug which I reuploaded to test to confirm the bug is still present.
File file type is being detected as image/jp2, but this shouldn't make it past upload since it shouldn't match '.jpg' file extension...
Version: unspecified
Severity: enhancement
URL: http://commons.wikimedia.org/wiki/Image:VIC_2_SECTION_%28Converted%29-1.jpg
Details
- Reference
- bz18803
Related Objects
Event Timeline
Probably a more general bug, for example [[hu:File:China.ogg]] is an mp3 file with .ogg extension.
ahmad.m.sherif wrote:
proposed patch
(In reply to comment #0)
File file type is being detected as image/jp2, but this shouldn't make it past
upload since it shouldn't match '.jpg' file extension...
I think this is because there is no mime type entry for jpeg2000 format in mime.types file. I made a patch anyway.
(In reply to comment #1)
Probably a more general bug, for example [[hu:File:China.ogg]] is an mp3 file
with .ogg extension.
IMHO, this is because 'audio/mp3' is the main mime type in mime.info and we use 'audio/mpeg' in mime.types instead of it, so MimeMagic::isMatchingExtension() returns NULL (which means continue) instead of false. It only needs a switch in one of the files.
Attached:
That should mean you can never upload those files at all, if they're unrecognized they can't match the known extension type...
Bryan.TongMinh wrote:
Added the entries to mime.types and mime.info in r88086.
There is a clear benefit: >8-bit depth with lossy compression for when a 90MB 16-bit lossless tif/png is overkill. The server always returns an error when I try to upload a large 16-bit tif image, and png is slightly smaller so it works but the metadata is lost. The upcoming jpeg-xs codec should support 16-bit as well so it would make sense to skip jpeg2000 and implement XS.