[Digikam-users] Color depth in lossless formats

Robert Susmilch robert at susmilch.com
Mon Aug 25 19:24:20 BST 2014


I too wrestled with formats and space.  I finally just went with an open
standard that will be well known for a long time (hopefully). I gave up
on digikam doing lossless conversions since it never worked and I
couldn't get it to do my whole collection of JPEG's so I wrote a script
that converts all my jpg's.  I then wrote a script that would download
new jpg's from my camera, load them into a holding folder, and then sort
them into YEAR/MONTH/DAY folders since that is also outside digikam's
scope.  Finally my backup script searches for all jpg's in my photos
folder, converts and auto orients them into PNG files with fingerprint
appended, and then optimizes them.  I think you should try optipng and
since you're on Ubuntu it should be in the repos

"*OptiPNG* is a PNG optimizer that recompresses image files to a smaller
size, without losing any information. This program also converts
external formats (BMP, GIF, PNM and TIFF) to optimized PNG, and performs
PNG integrity checks and corrections."

You get a savings up up to 20% I've seen on my testing, but it adds up.
Example of a 5000 DPI slide scan, scanned to jpg and tiff then converted
to PNG with "mogrify -auto-orient -format png -quality 100 filename.ext"

50M Aug 25 12:41 Scan-140825-0001.jpeg.png
18M Aug 25 12:40 Scan-140825-0001.jpg
167M Aug 25 12:40 Scan-140825-0001.tif
161M Aug 25 12:41 Scan-140825-0001.tiff.png

Then optimizing it

optipng -nx -preserve -clobber -zc9 -zm9 -zs0-3 -f0-5
Scan-140825-0001.tiff.png
** Processing: Scan-140825-0001.tiff.png
6542x4455 pixels, 3x16 bits/pixel, RGB
Input IDAT size = 168099168 bytes
Input file size = 168162013 bytes

Trying:
  zc = 9  zm = 9  zs = 0  f = 0        IDAT size = 168099168
  zc = 9  zm = 9  zs = 0  f = 1        IDAT size = 147256818
  zc = 9  zm = 9  zs = 1  f = 1        IDAT size = 146369673
  zc = 1  zm = 9  zs = 2  f = 1        IDAT size = 146369185
  zc = 9  zm = 9  zs = 0  f = 3        IDAT size = 144707250
  zc = 9  zm = 9  zs = 1  f = 3        IDAT size = 143759134
  zc = 1  zm = 9  zs = 2  f = 3        IDAT size = 143758332
                              
Selecting parameters:
  zc = 1  zm = 9  zs = 2  f = 3        IDAT size = 143758332

Output IDAT size = 143758332 bytes (24340836 bytes decrease)
Output file size = 143759629 bytes (24402384 bytes = 14.51% decrease)

New size,
138M Aug 25 12:41 Scan-140825-0001.tiff.png

And now for the JPG converted to PNG

optipng -nx -preserve -clobber -zc9 -zm9 -zs0-3 -f0-5
Scan-140825-0001.jpeg.png
** Processing: Scan-140825-0001.jpeg.png
6542x4455 pixels, 3x8 bits/pixel, RGB
Input IDAT size = 51874187 bytes
Input file size = 51894705 bytes

Trying:
  zc = 9  zm = 9  zs = 0  f = 0        IDAT size = 51874187
  zc = 9  zm = 9  zs = 0  f = 1        IDAT size = 36850006
  zc = 9  zm = 9  zs = 1  f = 1        IDAT size = 36757149
  zc = 9  zm = 9  zs = 0  f = 2        IDAT size = 35389940
  zc = 9  zm = 9  zs = 1  f = 2        IDAT size = 35207170
                              
Selecting parameters:
  zc = 9  zm = 9  zs = 1  f = 2        IDAT size = 35207170

Output IDAT size = 35207170 bytes (16667017 bytes decrease)
Output file size = 35208692 bytes (16686013 bytes = 32.15% decrease)

And new size,

34M Aug 25 12:41 Scan-140825-0001.jpeg.png

Got 32% savings on that one!

BTW, I choose PNG over TIFF because TIFF has too many standards and, at
least according to digikam, won't hold a lot of the metadata for the images.

Also use identify from either GM or ImageMagick to see that it's a
reporting inconsistency as you can write color depth as either 3x16 or
48 bit, or even 64 bit if you have 4 channels!

On 08/25/2014 03:51 AM, Niels Ott wrote:
> Hi there,
>
> I recently got a new used camera with 14MPix and now I feel like
> re-thinking my archiving options for edited images. So far, I had a
> 6MPix Pentax from whose PEF files I created PNG files. But with the
> 14MPix of the K-7, the PNGs range from approx. 69 to 76MB per image.
> Outch! So I checked out the other formats that DigiKam supports.
>
> Example (compression rates depend on particular image, of course):
>
> PEF/RAW:  14,7MB, "16 bpp", "not calibrated"
>
> TIFF:     72.6MB, "16 bpp", "RGB"
> PNG:      70.9MB, "16 bpp", "RGB"
> PGF:      62.6MB, "48 bpp", "RGB"
> JPEG2000: 31.5MB, "0 bpp",  "unknown"
>
> Now I'm wondering: What's up with the bpp values? Shouldn't they all be
> the same: 48bpp (3x16 bit per pixel in RGB mode)
>
> Also, I'm stunned by JPEG2000's apparently superior lossless performance
> (and flabbergasted by the tremendously slow implementation) - or is
> there simply something going wrong here?
>
> My DigiKam Version is the one of Ubuntu 12.04.5, namely 2.5.0
>
> I know that disk space is cheap nowadays, but I'm also doing audio
> recording and video stuff, so I fill up disks quickly and the JPEG2000
> compression level seems awesome to me. But how to check that it doesn't
> fool me and how safe is this to still work in the future? JPEG2000 is
> considered dead by many people.
>
> Thanks in advance for your ideas.
>
> Best
>
>    Niels
> _______________________________________________
> Digikam-users mailing list
> Digikam-users at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20140825/89b6d7e6/attachment.html>


More information about the Digikam-users mailing list