Another Slow SoC Day

So the morning (and by morning, I mean after 11:15 am when I woke up… ;-)) was spent trying, and failing, to figure out why my code seemed to be choking on YCbCr JPEG 2000 images. In an image with 480 columns and 640 rows, the code was failing when trying to get the color values for the first pixel in the 480th row. And it’s not a problem with JasPer itself, so far as I can tell, because the JasPer Image Viewer (jiv), which ships with JasPer, renders the image just fine.

Sadly, however, that’s the good news. The bad news is that so far as I can tell, the state of software support for transparency in JPEG 2000 images is pretty rickety. The list of applications that claim to create transparent images is few and far between. ImageMagick says it can convert images to JPEG 2000, but converting a .PNG with transparency to .JP2 resulted in a completely black one-channel image. There’s a plugin for PhotoShop that at least outputs the right number of channels, four, but no JPEG 2000 implementation I can find, except for Photoshop itself, will actually render such files. JasPer’s image viewer hits a runtime exception in a deeply-buried assert() that makes the whole program in question come crashing down. OpenJPEG does slightly better, insofar as it doesn’t crash, but it merely renders a black square and complains “JPEG2000: weird number of components.” QuickTime’s PictureViewer, which I understand to use Kadaku underneath, and IrfanView, which uses I-don’t-know-what, both likewise render naught but a black square. Sigh.

Oh, fine, there is also slightly better news: I’ve added a little smarts to render-jp2, so now it correctly renders both one-channel grayscale and regular 3-channel RGB images, and it also fails quietly (rather than, you know, crashing) if it runs across an image that it knows it can’t render. Also, high-precision (more than 8-bits-per-component) images can be decoded amd displayed, though not with full fidelity — the extra bits are thrown away before rendering. This is because the APIs available to image decoders in Firefox, so far as I know, are constrained to 8 bits per component.

I think it might be time to consult with Stuart about which direction to head in next. After cleaning up the code I have now, I could either spend time ripping out libjasper and replacing it with libopenjpeg, which would lead to little immediate benefit, or I could turn attention to writing an image-type finder service, to complement the existing Plugin Finder Service that says “Additional plugins are needed to display this page…” when you go to a Flash page on a machine without Flash currently installed. I’m leaning towards the latter route at the moment, as I think it will have the greatest positive impact on the general user population.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s