png huge

[Dr. Martin Senftleben]

Hi

I have another thing that puzzles me: I've set digikam to store images
as png, and always wonder how or rather why it makes out of a 2 MB jpg
file a 10 MB png file, even though the png compression is set to its
highest rate. Does png mean to increase file size by 5? Where does the
additional info, that couldn't be in the jpg file, come from?
Please point me to the place where this is explained, in case it has
been done already. I didn't find anything. Only the usual: jpg does
lossy compression, png doesn't.
But I see it maybe too simple: The jpg file has a limited amount of
info - uncompressed in a sense, because it's the original from which
the png file is made. The png file now takes this info and then gets
compressed to the maximum possible - yet it's 5 times larger.

Do I see that right, or am I completely on the wrong track?
When I make well readable screenshots e.g., the file size in png is
minimal (just a few kB), yet the image looks crisp and clear. So png
can be small, it doesn't have a tremendous overhead.

Any help in understanding this will be apprecieated.

Martin
--
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

[Marcel Wiesweg]

> I have another thing that puzzles me: I've set digikam to store images
> as png, and always wonder how or rather why it makes out of a 2 MB jpg
> file a 10 MB png file, even though the png compression is set to its
> highest rate. Does png mean to increase file size by 5? Where does the
> additional info, that couldn't be in the jpg file, come from?
> Please point me to the place where this is explained, in case it has
> been done already. I didn't find anything. Only the usual: jpg does
> lossy compression, png doesn't.
> But I see it maybe too simple: The jpg file has a limited amount of
> info - uncompressed in a sense, because it's the original from which
> the png file is made. The png file now takes this info and then gets
> compressed to the maximum possible - yet it's 5 times larger.
>
> Do I see that right, or am I completely on the wrong track?
> When I make well readable screenshots e.g., the file size in png is
> minimal (just a few kB), yet the image looks crisp and clear. So png
> can be small, it doesn't have a tremendous overhead.

I also once had the belief that PNG offers good image compression rates.
It does not. But it is very fast.
PNG uses Deflate compression - it's basically ZIP. This is a general
compression method, not developed for images. There is some prefiltering and
for certain images PNG will give good results, but for others not.

JPEG and newer compression formats know that their data is an image. They
operate in frequency domain, using discrete cosine transform or wavelet
functions. The latter can also be lossless, that's not the point.

Now your question about "additional info": The PNG does not care about
compression artifacts introduced by JPEG. JPEG lossy compression does not
necessarily reduce encoding entropy for the Deflate algorithm. (Note that JPEG
also includes lossless entropy encoding, after the first step of quantization
in the DCT domain)

Sound can be an analogy(*). Imagine a continuous tone of 500Hz. You record it
with 44k samples per second. With PNG, after some prefiltering, you would
encode these samples with entropy encoding. With JPEG or Wavelet, you would
get a table with "1" at 500Hz and "0" for all other frequencies. You then
encode that info with entropy encoding.

Please correct any wrong info here.

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

Le 18/01/2010 16:43, Martin Senftleben a écrit :

> Do I see that right, or am I completely on the wrong track?

you are completely on a wrong track.

10 Mega pixel image have a 10 mega bits size (and may be a little more
due to info management) when saved raw.

This size have nothing to do with the image *content* a it's
uncompressed. so saving as uncompressed PNG or TIFF gives nearly the
same size.

As an other answer said, the png compress algorithm is not really
efficient for most images, when jpeg can be very efficient.

That's also why nobody can know for sure what is the size of a jpeg
image: the size depends of the content

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

10 Mega pixel image have a 10 mega bits size (and may be a little more
due to info management) when saved raw.

10 mega bits x the number of color bits per pixels of course (so 10
mega bytes if 8 bits colors)

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

[Paul Hartman-2]

On Mon, Jan 18, 2010 at 9:43 AM, Martin Senftleben
<[hidden email]> wrote:
> Hi
>
> I have another thing that puzzles me: I've set digikam to store images
> as png, and always wonder how or rather why it makes out of a 2 MB jpg
> file a 10 MB png file, even though the png compression is set to its
> highest rate. Does png mean to increase file size by 5? Where does the
> additional info, that couldn't be in the jpg file, come from?

JPG is lossy, PNG is lossless.

> Please point me to the place where this is explained, in case it has
> been done already. I didn't find anything. Only the usual: jpg does
> lossy compression, png doesn't.

That's the correct answer. :) You cannot compare them. They are
completely different things.

> But I see it maybe too simple: The jpg file has a limited amount of
> info - uncompressed in a sense, because it's the original from which
> the png file is made. The png file now takes this info and then gets
> compressed to the maximum possible - yet it's 5 times larger.

An image of 100x100 pixels contains 10000 pixels of data. A PNG will
save all 10000 pixels exactly, and you will always be able to get the
original image every time.

A JPG saves an approximation of the original image. To a human eye, it
looks close enough to the original. But it's not the same, and never
will be. When you open the JPG your graphics program renders the JPG
to its own 100x100 image. When you save that as PNG, it's saving those
10000 pixels as PNG.

It's like asking why you can say a word with 1 character in Chinese
but 12 characters in German. Answer: because they are not the same. :)
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

[pshute]

"8 bit colour" is actually 8 bits for each of red, green and blue, isn't it?  Therefore 30MBytes in your example, not 10.





--------------------------

Sent using BlackBerry



----- Original Message -----

From: jdd <[hidden email]>

To: [hidden email] <[hidden email]>

Sent: Tue Jan 19 06:35:02 2010
Subject: Re: [Digikam-users] png huge



10 Mega pixel image have a 10 mega bits size (and may be a little more

due to info management) when saved raw.



10 mega bits x the number of color bits per pixels of course (so 10

mega bytes if 8 bits colors)



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

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

Le 18/01/2010 21:38, Peter Shute a écrit :
> "8 bit colour" is actually 8 bits for each of red, green and blue,
> isn't it?  Therefore 30MBytes in your example, not 10.

no. 10 mega pixels usually count all the pixel of any color
(commercially it's more fun)

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

[Gilles Caulier-4]

2010/1/18 jdd <[hidden email]>:

> Le 18/01/2010 16:43, Martin Senftleben a écrit :
>
>> Do I see that right, or am I completely on the wrong track?
>
> you are completely on a wrong track.
>
> 10 Mega pixel image have a 10 mega bits size (and may be a little more
> due to info management) when saved raw.
>
> This size have nothing to do with the image *content* a it's
> uncompressed. so saving as uncompressed PNG or TIFF gives nearly the
> same size.
>
> As an other answer said, the png compress algorithm is not really
> efficient for most images, when jpeg can be very efficient.
>
> That's also why nobody can know for sure what is the size of a jpeg
> image: the size depends of the content
>

Yes. PNG compression is not efficient for photo. But it's lossless,
like TIFF provide.

Alternative :

-  JPEG 2000 : wavelets, slow (due floating point algorithms), support
metadata, partially patented, implementation not fully complete in
opensource.
- PGF : wavelets, fast (integer algorithms), support metadata with
Exiv2 >= 0.19, not patetted, open source. I recommend it for
archiving.
- JPEG-XR : know as WMP, and HD-Photo, Wavelets based, metadata
support, fully patented, not opensource : Microsoft. Warning : this
format is already set as a new standard to replace JPEG in camera
device. Do you know  ??? M$ SDK compile and run under linux, but who
want to use it really ?

All theses format provide lossless compression which give a file size
approximately PNG size /2 (following my test). Of course this is
relevant of image contents...

JPEG2000 and PGF are supported in digiKam 1.0.0. Try it.

I have no plan to add JPEG-XR for the moment, until M$ SDK still as
closed source like implementation.

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

Le 18/01/2010 23:10, Gilles Caulier a écrit :

> Yes. PNG compression is not efficient for photo. But it's lossless,
> like TIFF provide.

I think that the encreasing of the image size have now reached a limit
(most good lens don't cope with more than 20 Mpix), so the race
between storage size and data size may be won by the storage...

at $100 for 1Tbyte disk, compressing will have less meaning

raw may be the future idal storage

(may)

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

[Michael Gerdau-3]

> (most good lens don't cope with more than 20 Mpix),

Do you have a source for that claim ?

I seem to recall that (good) color slides had a resolution in the range
of about 40 Mpix (no source, just rumors ;) and that that had been matched
by good lenses in the past.

Just curious, best wishes,
Michael
--
 Michael Gerdau       email: [hidden email]
 GPG-keys available on request or at public keyserver

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

[Daniel Bauer-2]

On Tuesday 19 January 2010 10:31:44, Michael Gerdau wrote:

> > (most good lens don't cope with more than 20 Mpix),
>
> Do you have a source for that claim ?
>
> I seem to recall that (good) color slides had a resolution in the range
> of about 40 Mpix (no source, just rumors ;) and that that had been matched
> by good lenses in the past.
>
> Just curious, best wishes,
> Michael
>

Just one example...
http://www.hasselblad.com/products/h-system.aspx
Not really a bad lens, isn't it?

:-)

Daniel
--
Daniel Bauer photographer Basel Barcelona
professional photography: http://www.daniel-bauer.com
_______________________________________________
Digikam-users mailing list
[hidden email]
https://mail.kde.org/mailman/listinfo/digikam-users

Le 19/01/2010 09:45, Michael Gerdau a écrit :
>> (most good lens don't cope with more than 20 Mpix),
>
> Do you have a source for that claim ?

yes, my own experience :-)

With a Canon EOS 50D, it's very easy to make lens fail if they are not
a very high quality. When I went from my 350D (8Mpix) to the 50D
(15Mpix), I could see some of my "good" lenses become much worst :-))

It's also current in photofans news papers to see lens that fit with a
box and not an other...

slides don't go very far from 15Mpix, nikon scanners stops à 4000
pixels/mm, that is appros24 Mpix and this exceed most slide value

of course, here I speak of 35mm film equivallent, bigger formats are
better

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

Le 19/01/2010 11:00, Daniel Bauer a écrit :

> Just one example...
> http://www.hasselblad.com/products/h-system.aspx
> Not really a bad lens, isn't it?

these are 50Mpix but on much larger sensors
(Kodak’s 50 Mpixel 36×48mm sensor)

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

[Dr. Martin Senftleben]

Hi,

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.

I recall the situation or my question:
from a jpg image file, a png image file is created. The jpg file can
contain only what is stored in it, right? The compression method is
lossy, so whatever is stored in there isn't complete already. This is
also - in my view - proven by the png that results when I transfer the
jpg file to the png format: they look absolutely alike, the png image
is in no way better than the "original" jpg image, it's only about 5
times larger.
The source of the png file is not the original raw image, but the
lossy compressed jpg file. Is it possible for the png to extract more
from the jpg file than there is in it? Or is it actually possible to
revert the compression made by the jpg format to get basically the raw
image (I doubt that, because then the jpg format wouldn't have lost
any of the original info)? If that's the case, I would understand, but
so far I couldn't read that from your replies.

Sorry if I appear a bit dumb on this...

Thanks for all replies

Martin
--
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

[Dr. Martin Senftleben]

Hi Gilles,

thanks for your reply and particularly for the list of different
formats.

Am Montag 18 Januar 2010 schrieb Gilles Caulier:
> Alternative :
>
> -  JPEG 2000 : wavelets, slow (due floating point algorithms),
>  support metadata, partially patented, implementation not fully
>  complete in opensource.
> - PGF : wavelets, fast (integer algorithms), support metadata with
> Exiv2 >= 0.19, not patetted, open source. I recommend it for
> archiving.

How well is pgf supported by other programs, also in the Windows
world? Do you know anything about that?

> I have no plan to add JPEG-XR for the moment,

Agreed. I would very much regret if the foto industry would go to use
this as future standard.

Martin


--
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

[Paul Hartman-2]

Hi Martin,

On Tue, Jan 19, 2010 at 10:45 AM, Martin Senftleben
<[hidden email]> wrote:

> Hi,
>
> 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.
>
> I recall the situation or my question:
> from a jpg image file, a png image file is created. The jpg file can
> contain only what is stored in it, right? The compression method is
> lossy, so whatever is stored in there isn't complete already. This is
> also - in my view - proven by the png that results when I transfer the
> jpg file to the png format: they look absolutely alike, the png image
> is in no way better than the "original" jpg image, it's only about 5
> times larger.

Correct. If you simply open a JPG and save as a PNG, you gain no
benefits. The PNG will be larger without giving you any advantage.

> The source of the png file is not the original raw image, but the
> lossy compressed jpg file. Is it possible for the png to extract more
> from the jpg file than there is in it? Or is it actually possible to
> revert the compression made by the jpg format to get basically the raw
> image (I doubt that, because then the jpg format wouldn't have lost
> any of the original info)? If that's the case, I would understand, but
> so far I couldn't read that from your replies.

You never get the original image back from the JPG (only a similar
image), but if the RAW was saved first as PNG then you could get
exactly the same image back from the PNG. So that is the advantage of
PNG compared to JPG.

Still, if you edit your JPG it is often better to save as PNG (or any
lossless format) because every time you save JPG it is losing more
data.*

* exception is some simple tasks like crop and rotate, there are tools
to do these things losslessly in JPG. jpegtran is the main one but
there are many more:
http://jpegclub.org/losslessapps.html

> Sorry if I appear a bit dumb on this...

Not dumb, it is confusing and I think you understand it now more than
before. :) In fact the same question was discussed in the GIMP mailing
list in the last few days.

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

[Gilles Caulier-4]

2010/1/19 Martin Senftleben <[hidden email]>:
> Hi,
>
> 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.
>
> I recall the situation or my question:
> from a jpg image file, a png image file is created. The jpg file can
> contain only what is stored in it, right?

It contain image data, image informations, metadata, icc color profile, etc...

>The compression method is
> lossy,

yes, definitively. Never use JPEG for archiving purpose. Use TIFF,
PNG, PGF or JPEG2000. JPEG is for web published, printing, etc...
never use JPEG in an editor.

>so whatever is stored in there isn't complete already. This is
> also - in my view - proven by the png that results when I transfer the
> jpg file to the png format: they look absolutely alike, the png image
> is in no way better than the "original" jpg image, it's only about 5
> times larger.

This is wrong. PNG compression is lossless. Editing the image and
saving again do not lost quality

> The source of the png file is not the original raw image, but the
> lossy compressed jpg file. Is it possible for the png to extract more
> from the jpg file than there is in it?

There is nothing more. don't forget: jpeg decompression is lossless,
recompression YES ! Look this video :

http://vimeo.com/3750507

Or is it actually possible to
> revert the compression made by the jpg format to get basically the raw
> image (I doubt that, because then the jpg format wouldn't have lost
> any of the original info)?

Definitively, no. Also, jpeg is 8 bits color depth, RAW is 12/14 bits
colors depth. You lost color quality too ! Never use JPEG for
archiving purpose.

PNG support 16 bits color depth. It's perfect to store demosaiced RAW
image data. (note JPEG2000, TIFF, and PGF support 16 bits color depth
too...)

Gilles Caulier
 If that's the case, I would understand, but

> so far I couldn't read that from your replies.
>
> Sorry if I appear a bit dumb on this...
>
> Thanks for all replies
>
> Martin
> --
> 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
>
>

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

[Geert Janssens]

On Tuesday 19 January 2010, Martin Senftleben wrote:

> Hi,
>
> 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.
>
> I recall the situation or my question:
> from a jpg image file, a png image file is created. The jpg file can
> contain only what is stored in it, right? The compression method is
> lossy, so whatever is stored in there isn't complete already. This is
> also - in my view - proven by the png that results when I transfer the
> jpg file to the png format: they look absolutely alike, the png image
> is in no way better than the "original" jpg image, it's only about 5
> times larger.
> The source of the png file is not the original raw image, but the
> lossy compressed jpg file. Is it possible for the png to extract more
> from the jpg file than there is in it? Or is it actually possible to
> revert the compression made by the jpg format to get basically the raw
> image (I doubt that, because then the jpg format wouldn't have lost
> any of the original info)? If that's the case, I would understand, but
> so far I couldn't read that from your replies.
>

In fact that is exactly what happens.

A compressed jpeg doesn't contain pixel definitions of your image. To display
the image, the jpeg encoded data is used to reconstruct a pixmap (or
"picture"), and this pixmap is displayed. This picture is not what your
original picture was before the jpeg compression, but it resembles it.

This converted image will be much bigger than your jpeg compressed file.
Others have illustrated this with numbers, I won't repeat that.

Now the conversion from jpeg to png follows the same route, although no
display step is involved.

First the jpeg compressed data is used to reconstruct a pixmap or image.
Remember, this image looks like your original image before the jpeg
compression but it is not. And this image will be much larger than the
compressed jpeg, because it contains information for every pixel in the new
image.

The next step will convert this full image into the png data format. This step
involves another form of compression that is much less efficient, but has the
advantage of being lossless.

So it is normal that your png image is much bigger than the jpeg is is created
from.

And the uncompressed raw images before jpeg/png compression, or after jpeg/png
decompression will be even much larger than either. This raw information is
what the computer uses to display the image or to print it or to manipulate it
in any way. The jpeg or png or other formats are only used to store the image
on disk.

I hope this adds some useful background information.


> Sorry if I appear a bit dumb on this...
>
Not at all. It's a complicated matter.

Regards,

Geert

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

[Dr. Martin Senftleben]

Hi,

Am Dienstag 19 Januar 2010 schrieb Martin Senftleben:
> > - PGF : wavelets, fast (integer algorithms), support metadata
> > with Exiv2 >= 0.19, not patetted, open source. I recommend it for
> > archiving.
>
> How well is pgf supported by other programs, also in the Windows
> world? Do you know anything about that?

I can answer this question at least with regard to one, for me
important, system: flickr can't handle pgf files.

I just did some experimenting on it and found that the pgf files are
of the same size as the png files (when a pgf file is created from the
png file). But it saves much faster, as you said.

Martin

--
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

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)

Notice also, but this is not likely to be the case with photos that
very small image files can be smaller in PNG than in JPG

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