png huge

[Andrew Goodbody]

Martin Senftleben wrote:
> with the many replies to my question I still believe I haven't been
> understood properly, even though I am very grateful for the replies
> which helped me to understand things better.

.jpg is a description of an image. The image is not described completely
(ie it is lossy) so the reconstructed image is only an approximation of
the original. The .jpg decoding process fills in for the lost
information as best it can.
.png records the whole of the image, both the parts provided by the .jpg
information and that filled in by the .jpg codec. This is where the
apparent extra data comes from.
But as others have said they record the image in such a different way
that the comparison is not fair, the size of the file is not an accurate
guide to the amount of information contained in it. In fact with a high
quality .jpg file it can be bigger than the corresponding .png but still
lose information that was contained in the original.

Andrew

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Marcel Wiesweg]

Again an analogy with sound formats may help:

The original (RAW) is a .WAV.
If you use plain standard zip compression to compress it, that's like using
PNG. Perhaps FLAC.
MP3 compares to JPEG,
AAC or similar to PGF or JPEG2000.

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Dr. Martin Senftleben]

Hi,

thanks for the sound analogy, but for me it's useless, as I have less
knowledge about soundfiles than about graphics files, where my
knowledge is also limited. I have no idea what AAC is.
I would miss ogg, though, in the list of sound files. But that should
be taken offlist.

Martin

Am Mittwoch 20 Januar 2010 schrieb Marcel Wiesweg:

> Again an analogy with sound formats may help:
>
> The original (RAW) is a .WAV.
> If you use plain standard zip compression to compress it, that's
>  like using PNG. Perhaps FLAC.
> MP3 compares to JPEG,
> AAC or similar to PGF or JPEG2000.
>
> _______________________________________________
> Digikam-users mailing list
> [hidden email]
> https://mail.kde.org/mailman/listinfo/digikam-users
>

--
E-Mail digital signiert mit Hilfe von GPG -
http://de.wikipedia.org/wiki/GNU_Privacy_Guard

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[Milan Knížek]

jdd píše v Út 19. 01. 2010 v 18:59 +0100:

> Le 19/01/2010 18:01, Gilles Caulier a écrit :
>
> > Never use JPEG for
> > archiving purpose.
>
> sorry, but it's perfectly safe to use jpg for archiving purpose given
> you wont ever edit the image again, what is what most of the people
> do. I will probably never edit again my 18000 photos :-).
>
> It's only superior quality images that needs raw storage (and then,
> raw is probably better than PNG)
>

I agree.

As a photographer, I aim for keeping the "untouched" original - i.e. RAW
or JPEG file from cameras and then the final edited version for
archiving, usually JPEG only.

It does not add much value to store the final image in PNG for
archiving. If it is touched already, I cannot revert the editing anyway.
If I want to have the possibility of reverting the edits, I would look
for layered GIMP/CinePaint xcf or Photoshop PSD and similar.

Though, PNG might still be a good option for archiving images with 16bit
colour depth per channel. The lossy-compressing alternatives (JPEG2000,
PGF) are not yet widely spread and supported, hence risky for archiving
purposes.

The trouble comes with organising the archive: writing meta info to
proprietary raw files is controversial and often unsupported, converting
to DNG does not result in the same raw data (unless keeping untouched
original raw data, too). At the moment, I add meta data only to JPEGs
and look for a moment, when digiKam would support easy handling of image
variants (raw + edit versions + archival version).

P.S. Those having multi-terabyte disk storage systems + 1 or better 2
another for backups, the above discussion is worthless, of course :-)

regards,

Milan Knizek
knizek (dot) confy (at) volny (dot) cz
http://www.milan-knizek.net - About linux and photography (Czech
language only)

_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 20/01/2010 20:54, Milan Knížek a écrit :

> P.S. Those having multi-terabyte disk storage systems + 1 or better 2
> another for backups, the above discussion is worthless, of course :-)

no. sync between various images versions and online upload (with 1Mb
upload adsl) are still unresolved problems. Backup is an other one;

There are the original image file (raw or jpeg fine), the processed
image (I delete many originals, crop many others...) and the metadata,
both saved by digikam and tagged *online* (now for me in piwigo).

Given online storage involve some kind of name obfuscation, because
one may have in the same online folder public and private images (and
it's too easy to gess private names from public ones), it becomes very
difficult, say, to find back the original from an oline lowres copy,
when *this* will be the real goal if suddently one particular image
become necessary (have to be edited again).

So we need probably some sort of thinking for the digikam future.

Right now I have an "original" folder, an "edited" folder (digikam
album) and online storage (three various.image size)

May be we could think of keeping all the metadata and various same
image versions in a simple zip file? most OS can read zip like
folders, so it could be simple (a little like openoffice store it's
images) - may be there is already a format for this?

piwigo already have a sync tool that's able to sync the metadata from
local storage to online storage and vice-versa without
uploading/downloading the complete (and heavy) files (it's name is
ploader - photo loader)

jdd

--
http://www.dodin.net
http://valerie.dodin.org
http://news.opensuse.org/2009/04/13/people-of-opensuse-jean-daniel-dodin/
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[pshute]

jdd wrote on Thursday, 21 January 2010 9:09 AM:

> Given online storage involve some kind of name obfuscation, because
> one may have in the same online folder public and private images (and
> it's too easy to gess private names from public ones), it becomes
> very difficult, say, to find back the original from an oline lowres
> copy, when *this* will be the real goal if suddently one particular
> image become necessary (have to be edited again).    
>
> So we need probably some sort of thinking for the digikam future.
>
> Right now I have an "original" folder, an "edited" folder (digikam
> album) and online storage (three various.image size)
>
> May be we could think of keeping all the metadata and various same
> image versions in a simple zip file? most OS can read zip like
> folders, so it could be simple (a little like openoffice store it's  
> images) - may be there is already a format for this?
>
> piwigo already have a sync tool that's able to sync the metadata from
> local storage to online storage and vice-versa without
> uploading/downloading the complete (and heavy) files (it's name is
> ploader - photo loader)  

Lightroom solves the problem I think you are describing here with its system of non destructive editing.  Associated with each original file is a set of editing and "publishing" instructions for creating edited versions.  I haven't used it much, but I assume you can work out the name of the original file from the name of one of the "published" files, as you can certainly do the reverse by looking at the "history" of the original file.

But I guess the non destructive edits are a side issue.  Basically, it seems they are keeping a history of all the "Save as" commands so that you can later tell which file has been created from which.  It shouldn't be hard for digiKam to check this file before displaying thumbnails so that it can group these files with their original, if necessary, and flag them as non-originals.

Doesn't work if you later rename them outside of digiKam, of course.
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users