Digikam image re-compression - is it reliable?

Digikam image re-compression - is it reliable?

Amos Shapira amos.shapira at gmail.com
Thu Jun 21 06:49:04 IDT 2012


Thanks.

On 21 June 2012 04:53, Shachar Shemesh <shachar at shemesh.biz> wrote:

>  On 06/20/2012 06:13 AM, Amos Shapira wrote:
>
> Hi,
>
> I'm preparing a disk-on-key with family photos to send to my mum and
> noticed something a bit unexpected.
> Most of the photos were taken with a Canon EOS 300D, maximum resolution
> and minimum compression.
> Some were taken with Android phone and iPhone 4.
> I use Digikam on Debian to manage my photos.
> The total space of the original images (including movies, which weren't
> touched) was ~7.6Gb.
> The total space after re-compression using default parameters (75%, JPEG,
> no resizing) - < 1Gb.
>
>  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).
>
> 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.
>
> 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.
>
> 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.
>
> I hope this enhances your understanding, and therefor your ability to rely
> on the compression.
>
> Shachar
>
>
>
> --
> Shachar Shemesh
> Lingnu Open Source Consulting Ltd.http://www.lingnu.com
>
>


-- 
 [image: View my profile on LinkedIn]
<http://www.linkedin.com/in/gliderflyer>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.cs.huji.ac.il/pipermail/linux-il/attachments/20120621/cf2285ba/attachment-0001.html>


More information about the Linux-il mailing list