Jump to content

JPG Compression - Under 100% results in a larger file size?


Recommended Posts

I'm sure this has been asked before since it's such a basic question, but I searched and couldn't find.

Why does Paint.Net save a 200 KB JPG file at 90% and end up with a larger file (by as much as 50k in this example), after I remove information (i.e. I will crop out a portion of the image, resulting in a smaller image in terms of height/width).

I would assume that a 100% ratio would end up with a file of equal size (all bytes preserved), and anything less than that would be a smaller file (due to more compression and information loss).

What am I missing?

Link to comment
Share on other sites

Your original JPG file was probably compressed at a higher level and lower quality than you're saving it as.

Unless the original was compressed at 100%, then there really can be no guarantee that a smaller (physically) image will be smaller in terms of filesize.

xZYt6wl.png

ambigram signature by Kemaru

[i write plugins and stuff]

If you like a post, upvote it!

Link to comment
Share on other sites

Your original JPG file was probably compressed at a higher level and lower quality than you're saving it as.

Unless the original was compressed at 100%, then there really can be no guarantee that a smaller (physically) image will be smaller in terms of filesize.

Maybe I'm missing something obvious ... but since an image can never be "improved" by software once the bytes are gone due to lossy compression, how can there ever be justification for a LARGER filesize after reducing the height/width?

Even if I selected 100%, I'd expect a smaller size because for the same compression and a smaller image, less bytes are needed. The fact that I am making the image dimensions smaller AND reducing the compression ratio below 100%, and ending up with a larger file, makes no sense.

I've been programming for years ... something doesn't seem right here.

Link to comment
Share on other sites

Your original JPG file was probably compressed at a higher level and lower quality than you're saving it as.

Unless the original was compressed at 100%, then there really can be no guarantee that a smaller (physically) image will be smaller in terms of filesize.

Maybe I'm missing something obvious ... but since an image can never be "improved" by software once the bytes are gone due to lossy compression, how can there ever be justification for a LARGER filesize after reducing the height/width?

Yes, but a JPG compression algorithm can't tell at what level the image was previously compressed. For all it knows, all of the artifacts are intentional and part of the image, and will do its very best to preserve the image as-is if you choose a high quality, artifacts and all.

xZYt6wl.png

ambigram signature by Kemaru

[i write plugins and stuff]

If you like a post, upvote it!

Link to comment
Share on other sites

Yes, but a JPG compression algorithm can't tell at what level the image was previously compressed. For all it knows, all of the artifacts are intentional and part of the image, and will do its very best to preserve the image as-is if you choose a high quality, artifacts and all.

I see what you're saying, but JPEG is a compression algorithm.

If the original image has larger dimensions than the one that's being saved, I don't see any logic in the resulting file size being LARGER than the original.

If I reduce a 10 x 10 pixel image to 8 x 8, under what circumstances can an INCREASE in file size be justified? The JPEG algorithm can't add additional information to the image, so the only logical outcome would be a smaller filesize, even at "100%".

I'm clearly missing something here.

Link to comment
Share on other sites

What the hell? I just posted something and it's not here.

Anyway, all lossy compression algorithms only control the closeness of the output relative to the input. Neither JPG nor any other lossy compression algorithm will get a lower filesize just because the image was full of compression artifacts to begin with. With a high quality, they compression artifacts will be the same (or nearly so) to the original ones, but with a higher filesize. With low quality, you'll get entirely new compression artifacts on top of the old ones, in exchange for a low filesize.

xZYt6wl.png

ambigram signature by Kemaru

[i write plugins and stuff]

If you like a post, upvote it!

Link to comment
Share on other sites

I don't get it.

I just don't see how it could ever end up with a larger file.

Because it's a compression algorithm, if it determines that the end result of the algorithm results in a file that is even 1 byte larger, it should discard the results of the algorithm and just return the original bytes.

Because no information is added, I can't see why it would ever result in a larger file. If the JPEG algorithm in this case can't do its job (reducing file size while attempting to preserve image quality), then give up and just stick with the original.

I can see no justification for me cropping 2000 pixels from an image and ending up with a LARGER file. That's broken.

Link to comment
Share on other sites

Because it's a compression algorithm, if it determines that the end result of the algorithm results in a file that is even 1 byte larger, it should discard the results of the algorithm and just return the original bytes.
That's just stupid. If the image has not been modified, then just don't resave it. If you have changed it in any way, then of course it can't just use the original bytes.

xZYt6wl.png

ambigram signature by Kemaru

[i write plugins and stuff]

If you like a post, upvote it!

Link to comment
Share on other sites

In addition, you have to remember that Paint.NET adds metadata to the file that changes the filesize. In extremely small files, that amount can be a rather large thing; if the original image had no metadata, adding any will balloon the filesize quite a bit.

Actually, I heard about a "JPEG Compression algorithm" that essentially just deleted the metadata from an image...what a scam...

 

The Doctor: There was a goblin, or a trickster, or a warrior... A nameless, terrible thing, soaked in the blood of a billion galaxies. The most feared being in all the cosmos. And nothing could stop it, or hold it, or reason with it. One day it would just drop out of the sky and tear down your world.
Amy: But how did it end up in there?
The Doctor: You know fairy tales. A good wizard tricked it.
River Song: I hate good wizards in fairy tales; they always turn out to be him.

Link to comment
Share on other sites

In addition, you have to remember that Paint.NET adds metadata to the file that changes the filesize. In extremely small files, that amount can be a rather large thing; if the original image had no metadata, adding any will balloon the filesize quite a bit.

Actually, I heard about a "JPEG Compression algorithm" that essentially just deleted the metadata from an image...what a scam...

Paint.net "metadata" aside (is that part of the JPEG standard?)... I had a 100k JPEG go to 150k after cropping a large portion of it.

Under no circumstances should a compression algorithm return an image that has more bytes after "compressing" it. At worst, it should add (original + metadata), meaning 0% compression. A 50k increase to a 100k file is ridiculous.

I'm still waiting for an answer that addresses that.

Link to comment
Share on other sites

Every answer has addressed that.

1. Paint.NET loads the image into memory. At that point, the original filesize is irrelevant; it's pure, raw, uncompressed pixels now.

2. You change something on it. At this point, even if PdN had the ABILITY to re-save as an identical file, it couldn't. You'd be saving with no changes applied.

3. You save it. Paint.NET adds metadata (filesize+) and then compresses it (which makes a file whatever size it can be).

It's not an INCREASE in filesize. It's a replacement of the filesize that happens to be larger. Paint.NET doesn't have a Jpeg compression algorithm to your liking? Re-save it in another program that does. It's that simple. You'd have the same issue if Paint.NET had a better Jpeg compression algorithm than whichever other one you're using, but you wouldn't be complaining then. :-P

 

The Doctor: There was a goblin, or a trickster, or a warrior... A nameless, terrible thing, soaked in the blood of a billion galaxies. The most feared being in all the cosmos. And nothing could stop it, or hold it, or reason with it. One day it would just drop out of the sky and tear down your world.
Amy: But how did it end up in there?
The Doctor: You know fairy tales. A good wizard tricked it.
River Song: I hate good wizards in fairy tales; they always turn out to be him.

Link to comment
Share on other sites

It's not an INCREASE in filesize. It's a replacement of the filesize that happens to be larger.

Clearly that makes no sense ... it isn't an increase in size, it's just larger?

I am just confused on how an image can become larger than (original image size + new Paint.Net metadata), ever.

If (original image + Paint.Net JPEG algorithm + metadata) results in a larger file than (original image + Paint.Net metadata), then what is the advantage of the algorithm? Why not just skip that step and stay with an image that 1) is higher quality (because its unaltered) and 2) has a smaller file size?

Link to comment
Share on other sites

Clearly that makes no sense ... it isn't an increase in size, it's just larger?

I think what he means to tell you is that the original file is just thrown away, and replaced by a newly made compressed file that can have Any size - depending on the quality setting and dimensions and on how "compressionable" it is (gradients and big pieces of only 1 colour will be far smaller than a small piece of randomness)

I would write plugins, if I knew what kind of plugins were needed.. :(

Link to comment
Share on other sites

Harold is exactly right. Paint.NET has no way of knowing the compression algorithm of a file saved using another program, so it can't just "go back to" that. It's not like a box that you just throw all the pixels back into; you have to have the specific algorithm, or you won't get the same results.

It's not mostly the metadata. I'm saying that that can account for a good deal in smaller files.

 

The Doctor: There was a goblin, or a trickster, or a warrior... A nameless, terrible thing, soaked in the blood of a billion galaxies. The most feared being in all the cosmos. And nothing could stop it, or hold it, or reason with it. One day it would just drop out of the sky and tear down your world.
Amy: But how did it end up in there?
The Doctor: You know fairy tales. A good wizard tricked it.
River Song: I hate good wizards in fairy tales; they always turn out to be him.

Link to comment
Share on other sites

I thought some people might want to reply, but the predominant opinion seems to be that I should lock this. That's where I was leaning anyway, so here it goes.

Look, the fact is that you can choose one of a couple of answers to your question:

1. Compression varies between programs. Metadata varies between programs. Even with smaller pixel sizes, the file size can still grow if the compression algorithm isn't as good.

That is the correct answer, but if you don't like it, I offer you a couple more.

2. Paint.NET is a bad, bad, evil program that only wants to hog all your hard drive space and rob you of all joy in life.

3. The computer fairies are impish creatures who increase your filesize at their own whims.

4. Astrology.

There ya go. Pick your answer. :-)

Thread Locked

 

The Doctor: There was a goblin, or a trickster, or a warrior... A nameless, terrible thing, soaked in the blood of a billion galaxies. The most feared being in all the cosmos. And nothing could stop it, or hold it, or reason with it. One day it would just drop out of the sky and tear down your world.
Amy: But how did it end up in there?
The Doctor: You know fairy tales. A good wizard tricked it.
River Song: I hate good wizards in fairy tales; they always turn out to be him.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
 Share

×
×
  • Create New...