<div dir="ltr">Thanks.<br><br><div class="gmail_quote">On 21 June 2012 04:53, Shachar Shemesh <span dir="ltr"><<a href="mailto:shachar@shemesh.biz" target="_blank">shachar@shemesh.biz</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="im">
<div>On 06/20/2012 06:13 AM, Amos Shapira
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,<br>
<br>
I'm preparing a disk-on-key with family photos to send to my mum
and noticed something a bit unexpected.<br>
Most of the photos were taken with a Canon EOS 300D, maximum
resolution and minimum compression.<br>
Some were taken with Android phone and iPhone 4.<br>
I use Digikam on Debian to manage my photos.<br clear="all">
The total space of the original images (including movies, which
weren't touched) was ~7.6Gb.<br>
The total space after re-compression using default parameters
(75%, JPEG, no resizing) - < 1Gb.<br>
<br>
</div>
</blockquote></div>
Here's a brief, and probably completely incorrect on several counts,
explanation of what JPEG compression does (and, for that matter,
also the single frame compression element of MPEG, MPEG2, MPEG4,
H264 and just about any lossy picture compression).<br>
<br>
The picture is divided into squares. Each square is processed with
an algorithm called Discrete Cosine Transform (or DCT). If you know
Fourier transform, this is essentially the same thing, only in 2D.
The resulting is a square of the same size, but with each component
in it representing some "frequency", rather than a single pixel.<br>
<br>
And here's the thing. Some positions in this square are more
important than others. The practical upshot is that getting the
value for some of the positions in this square will result in errors
in the picture that are more visible to the human eye than others.
Coincidentally, some positions in this square also tend to have
lower values (formally, the waves these positions represent have a
lower energy in the actual picture). The encoding allows the final
image format to not contain the full square, but leave out a certain
part of it.<br>
<br>
So, for lossless JPEG, all you do is take those components that have
energy, and use those. This still provides a considerable saving on
the uncompressed size. You didn't say how much each picture took,
but an uncompressed 24bits/pixel 1920x1280 image will take a little
over 7MB. Lossless compression should save about half of that.
Lossless JPEG can, depending on the actual picture, be about 3MB.
Allowing even a small amount of lossiness (say, JPEG 95%) should
bring you down to about 2MB, depending on the actual picture. As
usual, the law of diminishing returns is in effect. You pay little
visual artifacts for the initial reduction of size, and much more
later.<br>
<br>
I hope this enhances your understanding, and therefor your ability
to rely on the compression.<span class="HOEnZb"><font color="#888888"><br>
<br>
Shachar
<blockquote type="cite">
</blockquote>
<br>
<br>
<pre cols="72">--
Shachar Shemesh
Lingnu Open Source Consulting Ltd.
<a href="http://www.lingnu.com" target="_blank">http://www.lingnu.com</a>
</pre>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr">
<a href="http://www.linkedin.com/in/gliderflyer" target="_blank">
<span>
<img src="http://s4.licdn.com/scds/common/u/img/webpromo/btn_viewmy_160x25.png" alt="View my profile on LinkedIn" height="25" width="160">
</span></a></div><br>
</div>