Rob Miracle <rwm@photo-miracles.com> writes: > Let me explain digital file formats first. > > The Nikon D100 records 3 channels of color in 12 bits of color depth for 6 > million pixels. Computers are by their nature based on 8 bit chunks of > data. Thus it takes 16 bits (2 8 bit chunks) to hold 12 bits of data. Just a niggle, but this isn't true at all, unless you're an Unquestioning IBM Believer (and there aren't many of them left). Doing things in 8-bit chunks is now almost universal, but this is a cultural artefact, not part of anything's "nature". In days gone by many computers worked in 6-bit, 12-bit, 18-bit, 60-bit, and many other units. > Secondly JPEG's compression works very well, however to work as well as it > does, it has to sacrifice some color data. Lets say you have a photo of > someone in a blue dress and you pick 4 pixels of that dress to look > at. The 4 pixels may very well have slightly different color > values. When JPEG compresses, it looks for colors that are near each other > and changes them to one color and stores the data with 4 blocks of the same > color which cuts the file size down since it only has to store the one > color. Wiht the D100 in JPEG fine mode this is barely noticeable to the > trained eye and nearly impossible for an untrained eye to spot. Hmm. Well, I think this might help someone to understand what's going on as a *very* rough approximation, but (AFAIK) it isn't anything like what jpeg does. What it does is a discrete cosine transform (rather like a Fourier transform, AIUI), and throws away enough of the smaller coefficients to get in the target compression. There is something you can know easily about what this means: it operates on fixed 8 x 8 pixel blocks, which you can learn more about than I could ever write by compressing a jpeg down to a ridiculous level, then viewing zoomed up so you see the 8x8 blocks. Another implication of this is that (probably: this is hand-waving, rather than rigorous empirical science) if you resize or crop the image arbitrarily, the new 8x8 blocks will be unrelated to the old ones, and jpeg will be working hard to find coefficients to represent the joins between blocks, which of course are artefacts you don't want at all. Thus you can expect a relatively big loss if for example you trim n pixels off the left or top of the image, where n is not a multiple of 8. However, if you tweak the colour balance (say), the blocks are the same, and in principle at least you should only suffer a minimal loss of quality with the next jpeg compression. (A clever bit of software could allow you to tweak colour values only and recode the coefficients, instead of recalculating from scratch [This is obvious, so it's probably already been granted a patent] - there is a program somewhere available that allows you to *rotate* jpegs with no loss at all, just by rearranging the coefficients.) Perhaps Bob T has experimented with cropping by 8n pixels? Brian Chandler ---------------- geo://Sano.Japan.Planet_3 Jigsaw puzzles from Japan at: http://imaginatorium.org/shop/
