In the last little while we started to receive the same error/bug report coming through the Error Reporting functionality within LandlordMax. The error coming back was:
Error refreshing logo image javax.imageio.IIOException : Unsupported Image Type
Now this seemed weird to us, because we had all kinds of validations on which types of images to accept within LandlordMax. Before I proceed, to give you some context, LandlordMax has the ability to import pictures (jpg’s and gif’s only) into it’s database for 2 things. You can import an image for your logo/letterhead which will appear at the top of all your reports, which is great for the property management companies that purchase LandlordMax (about 50-65% of our customer base). The other area where you can add pictures is for your tenants, buildings, and units. This is a new feature that many people requested and that we added with version 2.12.
Getting back to this bug, we added all kinds of validation checks when you import images, such as the file extension (does it end with .gif, .jpg, .jpeg, etc.). We also added validations where it tries to first read the file, in case someone tried to manually change the file extension. And so on. Basically a lot of validation checks!
Initially we received some error reports such as the one listed above, and we found that we had missed a few potential validation checks, which we added with one of the patches (version 2.12a). That did significantly reduce the number of error reports, but they didn’t fully go away. Of course not everyone upgrades right away, but with time it seemed to dwindle down very significantly to just a few random ones. However, like I had just said, it didn’t completely go away which we don’t like to see.
Yesterday, we were finally fortunate enough to have someone also send us their email address (an optional parameter in the Error Reporting Dialog Window) along with the Error Report. This was great for us in that we finally had a repeatable test case for this very elusive bug that we couldn’t replicate, and that was extremely rare. We immediately contacted this customer and had her send us the image she used for the logo/letterhead as we tracked it down to a specific line in the code. We got the image, saved it, and added it to our test database. No problems, no errors, no issues! What? That didn’t make sense.
We then contacted her saying we couldn’t reproduce the error and we would be very appreciative if she could send us her database so that we could investigate it in detail. She obliged us and when we immediately tried it we got the exact error. It didn’t make any sense…
So the next step was to manually extract the image from her database into an image file and try that. I know she already sent us the image, but you never know. We extracted the image and opened it up with an image viewing tool without any issues. Very confusing… This image opens up in our image viewing software but not in LandlordMax.
So we dug deeper. Nothing. I personally spent several hours looking at this issue with no luck. So onto the internet and Google Search. After another hour or two, I found a weird bug report from Sun (Bug ID# 5100094). This was the key to the issue. It appears that the Java language doesn’t support JPG images that were saved in CMYK mode and threw this exact exception. Like most people, I know what a JPG image is, but I don’t know the details of how it’s encoded, nor do I really want to know. Now I was forced to find out more about this.
Without getting into too many technical details, it appears that JPG’s can be encoded from a number of modes, with RGB being the most common by far, or at least that’s my understanding. CMYK mode exist, but it’s not very commonly used.
Therefore I quickly checked the images, and low and behold, the image I had extracted from the database was encoded in CMYK! But what about the image she had sent me before? Well I did some further investigation, and to show you just how prevalent RGB mode is, the image she had sent me was in RGB mode. I don’t know if it’s the browser that converted the image or what, but when I did “Save image as…” it saved it in RGB mode. I did some further testing, and when I saved the image in CMYK mode, both browsers weren’t always happy with the image (depending on how exactly I saved it). That was very surprising to me. So it wasn’t only LandlordMax that had difficulties with this image mode sometimes, the major internet browsers also did!
As soon as I converted the image to RGB mode, everything went smoothly and with no issue. This was probably the most brutal bug I’ve ever encountered (omitting concurrency issues and such and just limiting it to straight bugs). It wasn’t an issue with the software, so it wasn’t possible to track down in the code. It was an issue with the image file and the programming language’s support of the image type. The error message wasn’t very indicative of the error as it usual is. And I also can’t blame the Java language either if both the major internet browsers had difficulties with this image mode.
So now what are the options for LandlordMax? This particular mode is not supported by the programming language. Do we look for a third party component and buy it? This is a very expensive solution, it costs a lot of money, not to mention the integration time (which is probably going to cost more than the component)? Will it have other bugs? Testing costs… For the percentage of users, I don’t think this is a viable solution.
Right now I’m personally leaning towards doing an extra validation and trying to invisibly render it from the file directly before accepting it. I’m leaning towards it, I’m not satisfied with it yet as it will have a lot of performance overhead, every new image will have to be rendered before being accepted… Imagine if you add 100 pictures for your building unit and each one has to be rendered. Rather than take a few seconds to a minute to import, it could now take 5-10 or more minutes easily. Is it worth it? Could I do a check after the fact, when trying to render it? That’s a possible solution also but it opens up a whole other can of worms…
The reality is that we don’t yet have a solution to this issue. We’re going to further investigate our options and definitely solve it for the next major upgrade, which is now expected to be out next month rather than this month. This is probably the most challenging bug I’ve encountered simply because it was absolutely unobvious what the issue was, there was no way to track it down in the code, and there is no real, or obvious, solution to it.
For those of you who don’t program, I hope this gives you an idea of the effort that goes into producing a software like LandlordMax Property Management Software. And although this is probably the most challenging bug I’ve ever encountered, it’s also one of the most interesting because of its difficulty!