Hellllllla late, but I thought you guys (esp XnTriq) might be interested in this, since I wrote a jpeg parser a while back and have the information at hand.
IJG has a rather interesting way of computing the quality level, which is adding up parts of the quant table. Since almost no tool will use custom quant tables, sadly, let alone multiple tables in a single image, it works pretty well, and it's an easy way to map quality levels between apps.
Adobe's 0-12 scale mapped to Imagemagick's 0-100 scale:
78,81,86,89,90,91,92,91,92,93,95,97,99
(Between 5 and 6, chroma sampling goes from 2x2 to 1x1, thus the backtracking.)
The code ImageMagick uses to estimage the q level is in
ImageMagick-6.3.0/coders/jpeg.c starting at line 835. All of this is very fast, almost instantaneous, unlike jpgQ. JpegSnoop is better.
Frankly, I'm no fan of IJG's and IM's linear quant scaling, since the best are crowded at the top and it's useless below 60, but it has its uses.
For optimization, a simple "jpegtran -o -progressive <old> <new>" will do it, by stripping out exif, thumbnails, and any other extra information. You can custom compile an arithmetic version for 10% higher compression, but thanks to an old ibm patent nothing really supports those. I once had the software for that, but can't seem to find it now. (Once I figure out how to write xnview plugins, I might offer such a batch optimizer, if it isn't in xnview by then.)
Aaaanyway, the flip side is that not only does xnview have to use the same quant tables (which is very easy and doesn't need any of the above digression), it would also have to decide which blocks have been modified and recompress those, while storing the unmodified ones back to the new file unrecoded. This is because not only is there recompress error, but also a yuv->rgb->yuv conversion, which will trash lowlight areas nicely.
The best way I've seen to accomplish this is to keep a bitmap of "dirty" pixels, or just compare the final to the original, when saving, recompressing only those blocks that have changed pixels. Fortunately, jpeg is very amenable to this and doesn't really have inter-block dependencies.
I think it'd be neat to have in xnview, since it's a rare enough feature that it's still worth touting, especially for little edits like applying logos and datestamps. But its absense doesn't bother me much.