<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
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<br>
<br>
"<b>OptiPNG</b> 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."<br>
<br>
You get a savings up up to 20% I've seen on my testing, but it adds
up.<br>
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"<br>
<br>
50M Aug 25 12:41 Scan-140825-0001.jpeg.png<br>
18M Aug 25 12:40 Scan-140825-0001.jpg<br>
167M Aug 25 12:40 Scan-140825-0001.tif<br>
161M Aug 25 12:41 Scan-140825-0001.tiff.png<br>
<div class="moz-cite-prefix"><br>
Then optimizing it<br>
<br>
optipng -nx -preserve -clobber -zc9 -zm9 -zs0-3 -f0-5
Scan-140825-0001.tiff.png<br>
** Processing: Scan-140825-0001.tiff.png<br>
6542x4455 pixels, 3x16 bits/pixel, RGB<br>
Input IDAT size = 168099168 bytes<br>
Input file size = 168162013 bytes<br>
<br>
Trying:<br>
zc = 9 zm = 9 zs = 0 f = 0 IDAT size = 168099168<br>
zc = 9 zm = 9 zs = 0 f = 1 IDAT size = 147256818<br>
zc = 9 zm = 9 zs = 1 f = 1 IDAT size = 146369673<br>
zc = 1 zm = 9 zs = 2 f = 1 IDAT size = 146369185<br>
zc = 9 zm = 9 zs = 0 f = 3 IDAT size = 144707250<br>
zc = 9 zm = 9 zs = 1 f = 3 IDAT size = 143759134<br>
zc = 1 zm = 9 zs = 2 f = 3 IDAT size = 143758332<br>
<br>
Selecting parameters:<br>
zc = 1 zm = 9 zs = 2 f = 3 IDAT size = 143758332<br>
<br>
Output IDAT size = 143758332 bytes (24340836 bytes decrease)<br>
Output file size = 143759629 bytes (24402384 bytes = 14.51%
decrease)<br>
<br>
New size,<br>
138M Aug 25 12:41 Scan-140825-0001.tiff.png<br>
<br>
And now for the JPG converted to PNG<br>
<br>
optipng -nx -preserve -clobber -zc9 -zm9 -zs0-3 -f0-5
Scan-140825-0001.jpeg.png <br>
** Processing: Scan-140825-0001.jpeg.png<br>
6542x4455 pixels, 3x8 bits/pixel, RGB<br>
Input IDAT size = 51874187 bytes<br>
Input file size = 51894705 bytes<br>
<br>
Trying:<br>
zc = 9 zm = 9 zs = 0 f = 0 IDAT size = 51874187<br>
zc = 9 zm = 9 zs = 0 f = 1 IDAT size = 36850006<br>
zc = 9 zm = 9 zs = 1 f = 1 IDAT size = 36757149<br>
zc = 9 zm = 9 zs = 0 f = 2 IDAT size = 35389940<br>
zc = 9 zm = 9 zs = 1 f = 2 IDAT size = 35207170<br>
<br>
Selecting parameters:<br>
zc = 9 zm = 9 zs = 1 f = 2 IDAT size = 35207170<br>
<br>
Output IDAT size = 35207170 bytes (16667017 bytes decrease)<br>
Output file size = 35208692 bytes (16686013 bytes = 32.15%
decrease)<br>
<br>
And new size,<br>
<br>
34M Aug 25 12:41 Scan-140825-0001.jpeg.png<br>
<br>
Got 32% savings on that one!<br>
<br>
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.<br>
<br>
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!<br>
<br>
On 08/25/2014 03:51 AM, Niels Ott wrote:<br>
</div>
<blockquote cite="mid:53FAF928.1080803@delta-b.net" type="cite">
<pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/digikam-users">https://mail.kde.org/mailman/listinfo/digikam-users</a>
</pre>
</blockquote>
<br>
</body>
</html>