I've noticed a loss in quality when I import digital photos from my camera
and view/save in Preview.  The files are smaller than the original, and
there is a slight, albeit visually noticable, loss in quality.  Is this part
of the same issue?  CCG

> ----------
> From:         owner-macgroup at erdos.math.louisville.edu on behalf of Jerry
> Yeager
> Reply To:     macgroup at erdos.math.louisville.edu
> Sent:         Monday, March 28, 2005 4:06 PM
> To:   macgroup at erdos.math.louisville.edu
> Subject:      Re: MacGroup: lossless JPEG??? [bcc][faked-from]
> 
> There has been a lot of talk lately about improvements in the jpeg 
> compression ideas being used (Allume -- makers of StuffIt -- has some 
> new stuff out that is supposed to shrink jpeg files up to 30% without 
> any loss of quality) and a lot of speculation about how Apple is 
> somehow reading the scheme used to compress the original imported jpeg, 
> then using the exact same scheme to compress the newly saved image 
> (this is supposed to maintain quality longer, through more levels of 
> edits --- how Apple does this is also supposed to be a closely guarded 
> secret -- at least according to the tin-hat-wearing folks, a bit 
> doubtful since if Apple can get this info out of an arbitrary jpeg 
> image, so can anyone else.)
> 
> Not being a big iPhoto user (Go GIMP! Go PhotoShop!), I have only 
> followed those discussions out of idle curiosity.
> 
> But in terms of how iPhoto does do some of its wonders, you need to be 
> careful here. Apple cheats. (Reeeeaaalllllyyyy big toothy grin!!!!!)
> If you import a jpeg photo, make changes, quit, come back make changes, 
> quit et.c etc. the saved photo looks really good. Okay so far. But 
> there is a menu option that says "Revert to Original". Choosing this 
> takes you all the way back to the original imported image. So what 
> Apple is doing is keeping a history of your editing for the photo and 
> applying that to the original and showing you that. (Also if you take a 
> gander through the iPhoto library you will see lots of data files 
> popping up for your albums, especially after you start editing).
> 
> On the other hand, if you edit a photo, then Export that, then import 
> it back in, make changes, export it and import it again, etc. then you 
> will begin to see image quality degradation within a few generations 
> (using the jpeg format) that do not show up for the same edits on the 
> one that stays inside of iPhoto the whole time.
> 
> One thing that is creeping into the lexicon is the idea of what 
> "lossless" means. With these new attempts to make jpeg last longer 
> (instead of switching to the better jpeg2000 -- for jpeg compression) 
> there is a lot of talk of thing being lossless in image quality, but 
> not being a bit-for-bit identical copy. Hmm, it does sound like the 
> words are going to be altered here soon.
> 
> Shoot RAW NEFs, it's just better (smile).
> 
>                       Jerry
> 
> 
> 
> On Mar 28, 2005, at 11:00 AM, John Robinson wrote:
> 
> > Lee,
> >
> > Thanks, as usual for a great explanation, but just for your info. my 
> > eyes glaze over on most anything you say as you speak so far above my 
> > capabilities, but boy do I ever learn from you!!
> >
> > John R.
> >
> >
> >
> >
> > On Mar 28, 2005, at 10:54 AM, Lee Larson wrote:
> >
> >> On Mar 27, 2005, at 9:22 PM, Bill King puzzled:
> >>
> >>> I just read an interesting article posted on MacSurfer from the 
> >>> Syracuse Post-Standard newspaper.  It concerned the ability of 
> >>> iPhoto 5 to repetitively save a picture using JPG compression and 
> >>> apparently losslessly.
> >>>
> >>> I would love to hear for any graphics compression experts about the 
> >>> authenticity of this technique...
> >>
> >> I'm not a graphics expert, but I think I can explain what's going on.
> >>
> >> The JPEG scheme is actually a whole collection of different 
> >> compression techniques all lumped into one standard. The most common 
> >> one chosen is what's called "discrete cosine transform" (DCT) 
> >> compression. Within the DCT algorithm, you can choose the amount of 
> >> information to be retained. (It's just the value of a constant in the 
> >> formula.) The more information that's retained, the larger is the 
> >> size of the compressed file. It's possible to choose lossless DCT 
> >> compression, at the expense of almost no compression for complicated 
> >> images.
> >>
> >> You can see this in programs like Canvas, which has a slider control 
> >> to select the quality of the output image. Sliding it over to 100% 
> >> results in a big file with no quality loss.
> >>
> >> The JPEG scheme also includes a lossless algorithm called entropy 
> >> encoding which I believe is less often used than the DCT.
> >>
> >> I don't know which scheme Apple uses, but It's probably one of those 
> >> two.
> >>
> >> As a postscript to this, let me note that I've had disagreements with 
> >> so-called experts about this. They claimed that JPEG is an inherently 
> >> lossy format while I countered that it need not be. Most "experts" 
> >> don't really understand the capabilities of JPEG because most 
> >> programs don't take advantage of JPEG's real capabilities. I bring up 
> >> the DCT and their eyes glaze over.
> >
> >
> >
> > | The next meeting of the Louisville Computer Society will
> > | be March 22. The LCS Web page is <http://www.kymac.org>.
> > | List posting address: <mailto:macgroup at erdos.math.louisville.edu>
> > | List Web page: <http://erdos.math.louisville.edu/macgroup>
> >
> >
> -----------------------------------
> Someday, I will come up with a clever signature line. I am not sure if 
> I will use it or not, but I will come up with one.
> 
> 
> 
> | The next meeting of the Louisville Computer Society will
> | be March 22. The LCS Web page is <http://www.kymac.org>.
> | List posting address: <mailto:macgroup at erdos.math.louisville.edu>
> | List Web page: <http://erdos.math.louisville.edu/macgroup>
> 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
http://www.math.louisville.edu/pipermail/macgroup/attachments/20050328/84d472d7/attachment.html
 

Reply via email to