.jpg vs .png

>>57188575
>degrade
Ummm, m80, got some bad news for ya...

>>57188575
>Should I save low quality compressed images or higher quality images
>Space isn't an issue

Ummm... I don't know OP. Maybe you should shoot yourself.

>>57188575
>I know .png is larger

No you don't. It depends on the image - if you have fields of the same color in your image then PNG has a good chance of being smaller than JPEG.

But if there are some more complex structures in the image - say, a human face, or a city, or basically everything IRL - then JPEG is going to be smaller.

It depends on the image. Limiting yourself to one image type is retarded.

>>57188575
Also, why the fuck do you think JPEG will degrade faster than PNG? Copying/saving an image does not degrade it. That is bullshit talk instituted by retarded authors who have not understood how lossy compression works - unless you actually EDIT and then EXPORT the image into JPEG again it will not degrade.

>>57188696
/thread

>>57188728
Same here, i always giggle at people thinking that ctrl+c -> ctrl+v multiple times will lower the quality of lossless formatted pictures.

>>57188575
>but the normalfag answers I found seemed to recommend .jpgs only because .pngs are larger
>multiple copyings degrade the quality

What kinda reasoning is that?
Anyway
PNG excels at simple colours, which makes it excellent for anime pictures and other simple art (e.g. comics). If you convert a photo to PNG (from RAW) instead of PNG you'd get a higher quality picture (on average), but at a huge filesize.
JPG is intended for elaborate pictures, and photos. Its' shitty compression is not as noticleable on those, and the filesize is pretty small.

>>57188728
On the multiple copies thing, see >>57188728. This is digital, not analog. You transfer the same file as it is, you don't scan it (and when you want to copy it again) you don't scan the scan. The file is still a 1:1 copy of the original.

>>57188696
I was very much aware that those facts would seem to dictate that .png is optimal. My question is if there's anything else that I should consider, or if that initial analysis was complete.
>>57188728
I didn't think that. I entertained the idea because of those retarded authors. But it didn't make much sense to me so I wondered if they were misrepresenting things. That's why I asked about- since I suspected it was false.

>>57188807
How do you know we're not bullshitting you?

>>57188874
Nice FUD.

Image files (and files in general) don't degrade when copied. It is true that files encoded in lossy formats (e.g. JPEG for images, MP3 for sound, H264 for video...) can lose some data if re-encoded at the same quality/bitrate, but that will be barely noticeable.

JPEG (lossy) and PNG (lossless) were designed for completely different purposes: JPEG for saving photographs at user-specified quality/size loss ratios, PNG for losslessly saving images with flat colors and hard lines.

Use these formats for their goals.

>>57188575
>I'll mostly be saving paintings and anime art, if that makes any difference.

What's the source? A camera? Scanner?

File: 1465318339721.jpg (91KB, 445x472px) Image search: [Google]

91KB, 445x472px

>>57188575
pngs degrade less due to rotational velocidensity
especially on SSDs due to their low RPM

>>57188575
save digital images as png
photos as jpg

>>57188575
>currentYear
>not saving all of your images in a lossless format
Use PNG

File: 1477141618885.jpg (99KB, 1280x582px) Image search: [Google]

99KB, 1280x582px

>>57188575
As several people in this thread have stated, PNG is lossless and is good for images with flat colors, less gradients, and less variety. JPG is lossy, but is good for saving other types of images with more color variety.

Overall, as a rule of thumb, save photographs, or anything based in the real world (paintings probably fall into this) as JPG. Anime images are probably fine as PNGs if they're already saved as such. You might gain some file size reduction from converting, but since space isn't an issue, I wouldn't bother. And don't bother converting the other way, because that's not going to gain you anything. For example, pic related is your PNG converted to JPG at a fairly high quality setting, resulting in a decent file size reduction with no noticeable loss in quality.

>>57188575
Always store masters in a lossless format. Export to JPEG if you need a smaller file for the web or something.

>>57191918
This
Fuck lossy formats

File: 445565.png (356KB, 1280x582px) Image search: [Google]

356KB, 1280x582px

>>57188575
>whines about file quality
>whines about file size
>doesn't optimize his PNGs
Yeah, your a retard.

>>57188575
Use PNG for everything you can, if it's already as a jpg / jpeg then leave it as is. PNG is lossless.

>>57188575
save as jpeg with 85% quality to lower file size then resave as png so it become lossless
easy af

File: out.png (393B, 400x400px) Image search: [Google]

393B, 400x400px

png compression saves space by using the same bit for exact color values, so the fewer colors in an image, the smaller a png will be relative to jpg.

>>57194281
>my a retard.

File: 393.png (143B, 400x400px) Image search: [Google]

143B, 400x400px

>>57194439
>yadda yadda yadda being pretentious about file compression
>being unable to optimize file compression

>>57194510
how do you do that in gimp?

>>57194543
I *don't* do that in gimp.

>>57194551
How do you do that then?

>>57194543
https://github.com/google/zopfli

>>57194567
nope, that won't be as good.

>>57194543
I use PNGOutWin to do PNG optimisation.

>>57194617
Still not enough

>>57194579

./zopflipng --iterations=100 --filters=0meb ~/Desktop/zopfli.png ./zopfli.png
Optimizing /home/user/Desktop/zopfli.png
Input size: 143 (0K)
Result size: 143 (0K). Percentage of original: 100.000%
Result has exact same size

fite me irl

>>57194659
post your resulting image

>>57194281
>muh pngcrush
>muh optipng
come on

>>57194721
post better then

>>57194688
I will put it simpler: Your program is a port of zopflipng for Windows.

/zopflipng --iterations=100 --filters=0meb ~/Desktop/zopfli.png ./zopfli.png
Optimizing /home/user/Desktop/zopfli.png
Input size: 393 (0K)
Result size: 143 (0K). Percentage of original: 36.387%
Result is smaller
File ./zopfli.png exists, overwrite? (y/N) y

And I literally can't post it because it's a dupe of yours.

>>57194759
>implying

kay,
why don't you post any PNG file you like, and we can fight over it?

Keep the file small so that optim isn't too long to run

Who's this semen demon anyway?

File: 1477173328909.png (211KB, 500x361px) Image search: [Google]

211KB, 500x361px

>>57194787
kay let's say we'll work on this random PNG I found on this board
(post better if you can)

File: 1289488608428.png (984KB, 1100x1192px) Image search: [Google]

984KB, 1100x1192px

>>57194787

./zopflipng --iterations=100 --filters=0meb /media/pic/1289488608428.png ./1289488608428.png
Optimizing /media/pic/1289488608428.png
Input size: 1007953 (984K)
Result size: 716459 (699K). Percentage of original: 71.081%
Result is smaller

>>57194962
currently working on this >>57194941 but I'll get right back to you.

File: 1477175370577.png (196KB, 500x361px) Image search: [Google]

196KB, 500x361px

>>57194941

File: 200651.png (196KB, 500x361px) Image search: [Google]

196KB, 500x361px

>>57195110
Bitch please
And I'm not even done

>>57195145
>500 bytes

woe is me for not toggling on experimental crap

ITT no FLIF

>>57195156
moving goalposts much?

>>57195145
>>57195173

I'll save you the trouble

./pngout /media/pic/1289488608428.png 
 In: 1007953 bytes              /media/pic/1289488608428.png  /c2 /f0
Out:  722409 bytes             /media/pic/1289488608428.png  /c2 /f5

>>57195347
I don't see what your post has to add here

>>57195415
You're taking 45m to compress a 1MB image, so in that time, I downloaded pngout and compressed it to show its default opts are worse than zopfli's.

As well, it's outclassed in almost every scenario as shown by benchmarks:
https://blog.codinghorror.com/zopfli-optimization-literally-free-bandwidth/

>>57188575
>>57191707
Who is this grill.