I didn’t know that… From my initial impressions searching on Google I was pretty sure there were 20 or so different encodings. To be quite honest, I’m very ignorant as to the details of the JPG encodings, and I don’t really have an interest in knowing them, I’m just too busy on other higher priority items.

It’s s very interesting to know about the thumbnail! Thank you for sharing that information. Therefore from what I gather they aren’t part of the spec if their not in the header, something that was added after by Photoshop and similar software?

Thanks for the information, it’s very appreciated. In regards to the solution we’re going to implement, you’re comments and suggestions are still making me ponder which path to take… Sometimes I find that if I just sit on the options for a while, let it work in the back of my mind, it easier for me. At this point I haven’t decided yet.

Good luck with your solution.

You’re right, I skipped over the part that the code “only” lets you detect it, nothing more. You’re absolutely right, my apologees.

One thing though that I’ve been thinking of since then, no matter what kinds of checks we do, we still have to implement the code in case there is an error. For example, maybe there’s another format that will cause a similar issue. I’ve read something about the Photoshop thumbnail preview mode causing issues with many image renderers too.

So the question then becomes, do we just implement one solution or two? Seeing your code, it’s a fairly simple implementation, so it makes me want to implement such a check. But then I start to think about testing it. I’ve only come accross one image that has this issue (of course I can create others). But now how do I test for false positives?

Testing for false positives can become very complex, there are many image modes. Since we also have to implement the other solution because of this, is it worth going through this extra effort?

That’s a hard question. Right now I’m leaning towards no. Not because the solution is difficult, you provided a great succint solution (thank you!), but testing it is very difficult. We need to test images that have this issue, and all other image formats to make sure we’re not preventing a valid mode. This false positive testing is starting to scare me in terms of costs…

And if we look at the gain, since we have to implement the other solution that deals with all cases, what’s the gain of this additional check? It’s an initial performance gain when first importing the images (so we never have to try to render them). This is why I’m going to go with just the simple solution of catching the errors when rendering at this time. Yes it’s more expensive to implement, but we have to implement it anyways, and it’s much cheaper to test.

And yes, you’re absolutely right, sometimes the obvious simple solution is the hardest to see! I know I’ve been guilty of that one more than once

These days, I always try to find some type of justification for what we add into LandlordMax. When you’re smaller every penny counts that much more! It’s also easy to fall into the trap of not fixing bugs, but I’m very opposed to this because I’m strong believer of design debt. However, if the bug fix is very large, the frequency of occurence very low, and the spread non-existant (only affects this, it does not increase design debt), then sometimes you need to look at the alternatives, as was the case with this bug.

To give you an idea of some bug fixes that we can’t justify with just the model I described above is performance enhancements. We’ve done some major performance enhancements with the upcoming major release (as well as with version 2.12). We spent a lot of time and effort, almost 1/2 of it was performance based!

Will this automatically convert to sales? Maybe, maybe not. However if we hadn’t made these enhancements we would be acquiring a lot of design debt which would have hit us later. Maybe not tomorow, but soon enough. When it comes to performance you’re only as strong (fast) as the weakest (slowest) link in your chain.

Also consider your blog related to this where you explain that it is not cost effective for you to go with a developer oriented solution, but need to go more with a business oriented solution. Consider that Microsoft and the Firefox crew have huge budgets and may be only considering the developer oriented solution. As you get bigger sometimes you can get blinded to the simple solution.

Good luck.

Please take this with the utmost of respect. If it was this simple (I’m not implying that getting to this snippet didn’t take a lot of time and understanding) where one could just write out the code (you mention you just wrote it and didn’t thoroughly test it), then it makes be believe that Mozilla and Internet Explorer should have been able to get it right with all their massive resources? So the question is why didn’t they?

By this reasoning, I’m going to assume there’s more than meets the eye…

The code is not thoroughly tested. I just wrote it.

Here is the header part of the JPEG spec.

SOF0: Start Of Frame 0:
~~~~~~~~~~~~~~~~~~~~~~~

– $ff, $c0 (SOF0)
– length (high byte, low byte), 8+components*3
– data precision (1 byte) in bits/sample, usually 8 (12 and 16 not
supported by most software)
– image height (2 bytes, Hi-Lo), must be >0 if DNL not supported
– image width (2 bytes, Hi-Lo), must be >0 if DNL not supported
– number of components (1 byte), usually 1 = grey scaled, 3 = color YCbCr
or YIQ, 4 = color CMYK)
– for each component: 3 bytes
– component id (1 = Y, 2 = Cb, 3 = Cr, 4 = I, 5 = Q)
– sampling factors (bit 0-3 vert., 4-7 hor.)
– quantization table number

Remarks:
– JFIF uses either 1 component (Y, greyscaled) or 3 components (YCbCr,
sometimes called YUV, colour).

The spec is on http://www.wotsit.org if you want to look at it fully. The segment definitions are near the end.

Thanks for posting all the code!

Do you know how thoroughly this code has been tested? The reason I ask is because from what I’ve heard the way the meta data is encoded can be slightly different (the specs are a little ambigiuous at times). From I see in your code, you’re expecting the CMYK flag (aka. image type flag) to appear at a specific location within the header block (9 bytes from the start of the header)…

From what I understand, Photoshop for example can also throw in a thumbnail within the image which can skew the whole thing too? Do you know anything about this?

import javax.imageio.ImageIO;
import javax.swing.JFrame;

public class Test extends JFrame {
Image im;
public void loadImage(InputStream in) throws Exception {
ByteArrayOutputStream bout = new ByteArrayOutputStream();
byte buffer[] = new byte[8192];
int read = -1;
do {
read = in.read(buffer);
if(read != -1) {
bout.write(buffer, 0, read);
}
} while(read != -1);
byte imageData[] = bout.toByteArray();
int startOfHeader = -1;
for(int i=0;i<imageData.length – 1;i++) {
if((imageData[i] & 0×000000ff) == 0xff && (imageData[i + 1] & 0×000000ff) == 0xc0) {
startOfHeader = i;
break;
}
}
//if image type = 4 CYMK mode is used
int imageType = bout.toByteArray()[startOfHeader + 9];
System.out.println(”type = ” + imageType);
im = ImageIO.read(new ByteArrayInputStream(bout.toByteArray()));
setSize(im.getWidth(null), im.getHeight(null));
}
public void paint(Graphics g) {
g.drawImage(im, 0, 0, this);
}
public static void main(String args[]) {
Test t = new Test();
try {
t.loadImage(new FileInputStream(”any_image.jpg”));
t.setVisible(true);
t.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
catch(Exception e) {
e.printStackTrace();
}
}
}

for(int i=0;i