Steps to reproduce: 1: Open http://echoone.com/filejuicer/formats/jpeg2000-safari.html The JPEG 2000 does not show up or shows up in funny colors as if decompression was stopped prematurely when only the blurry outlines were decompressed. When you hit reaload it (perhaps a couple of times) will display correctly. Now the jpeg 2000 is in the cache and the page may continue to work until you empty the cache. I have not checked if Apaches content negotiation can serve jpeg 2000 to Safari and JPEG to everybody else. The QuickTime plugin can show it correctly.
Confirmed with WebKit r15138.
The image is served with a content-type of "image/jp2", which is apparently valid (http://www.iana.org/assignments/media-types/image/jp2): $ curl -I http://echoone.com/pictures/filejuicer/gold.jp2 HTTP/1.1 200 OK Date: Sat, 23 Feb 2008 02:20:07 GMT Server: Apache/2.2.6 (Unix) mod_ssl/2.2.6 OpenSSL/0.9.7l DAV/2 PHP/5.2.4 Last-Modified: Thu, 18 Aug 2005 15:50:33 GMT ETag: "af561-fb41-3fe9e2c616440" Accept-Ranges: bytes Content-Length: 64321 MS-Author-Via: DAV X-Hardware: PowerMac G4 Cube 449 MHz / 128 MB X-Administrative-Fuel: Intravenous Caffeine Drips... Content-Type: image/jp2 On Leopard, reloading the test page gives various results from no image at all (just a grey page) to various levels of decoding (resulting in B&W or color images that have varying degrees of fuzziness).
(In reply to comment #2) > The image is served with a content-type of "image/jp2", which is apparently > valid (http://www.iana.org/assignments/media-types/image/jp2): > Using the latest Leopard (10.5.2 - tried on 2 macs) the bug seems to be gone - It may have been fixed a long time ago. Unfortunately JP2 compression no longer compress this well on Mac OS with Preview (or my app - DoubleTake). Now the compression setting for smallest file size gives larger files than jpg - (rdar://5723704).
(In reply to comment #3) > Using the latest Leopard (10.5.2 - tried on 2 macs) the bug seems to be gone - > It may have been fixed a long time ago. > Unfortunately JP2 compression no longer compress this well on Mac OS with > Preview (or my app - DoubleTake). Now the compression setting for smallest file > size gives larger files than jpg - (rdar://5723704). I still saw the issue on 10.5.2 on a Power Mac Quad G5. It was very reproducible for me. Also reproducible with a local debug build of WebKit r30353 with Safari 3.0.4 (523.12.2) on Mac OS X 10.4.11 (8S165). You may have to empty your cache to see the bug as well.
(In reply to comment #4) > I still saw the issue on 10.5.2 on a Power Mac Quad G5. It was very > reproducible for me. > > Also reproducible with a local debug build of WebKit r30353 with Safari 3.0.4 > (523.12.2) on Mac OS X 10.4.11 (8S165). Note that both of these systems were PowerPC-based. I wonder if it works on Intel but not PowerPC?
(In reply to comment #5) > Note that both of these systems were PowerPC-based. I wonder if it works on > Intel but not PowerPC? No, I just reproduced this with Safari 3.0.4 (5523.15) and original WebKit on Mac OS X Server 10.5.2 (9C31) on a Mac mini Core 2 Duo.
I have reproduced it once again (as gray color filling the browser window) on my TiBook G4 with Safari 3.0.4 running Leopard. But only once. Reloading the page made it work fine, and clearing the cache did not recreate the bug. My MacMini G4 (Tiger+Safari 3.0.4) did not show it. My other MacBook Pro (Leopard) did not show it. I wonder if it could be a timing issue - how fast my server delivers the file. I checked my server log - and the apache logfile says that all 64321 bytes were sent properly. Of course I have excellent connection to my own server. Henrik
(In reply to comment #7) > I wonder if it could be a timing issue - how fast my server delivers the file. > I checked my server log - and the apache logfile says that all 64321 bytes were > sent properly. > Of course I have excellent connection to my own server. There is definitely a race condition going on since the behavior changes on each reload for me (various degrees of "focus" and sometimes appearing in black-and-white).
<rdar://problem/6056232>
Jpeg2000 now compress (4 times) less than JPEG in Preview at the lowest quality setting. I wonder why Apple decided to block high compression ratios - perhaps to direct jpeg 2000 use towards higher quality images instead of higher compression.
(In reply to comment #10) > Jpeg2000 now compress (4 times) less than JPEG in Preview at the lowest > quality setting. I wonder why Apple decided to block high compression ratios - > perhaps to direct jpeg 2000 use towards higher quality images instead of higher > compression. Please file a bug using <https://bugreport.apple.com/> about this issue. If you don't have an ADC account, you may sign up for one at <https://connect.apple.com/>.
(In reply to comment #11) > (In reply to comment #10) > > Jpeg2000 now compress (4 times) less than JPEG in Preview at the lowest > > quality setting. I wonder why Apple decided to block high compression ratios - > > perhaps to direct jpeg 2000 use towards higher quality images instead of higher > > compression. > > Please file a bug using <https://bugreport.apple.com/> about this issue. If > you don't have an ADC account, you may sign up for one at > <https://connect.apple.com/>. > Here is the radar link to the compression ratio bug for jpeg 2000 in Preview <rdar://problem /5723704>
This works well on recent Mac OS X versions (10.10.x.) now.