What is your favorite image format? Why is it PNG?
pngslim is the best I'm aware of. It's gotten significantly faster in recent revisions, though I haven' tested if any compression efficiency has been lost because of that. Though it still seems to have all the filtering etc options still available, they just aren't an automatic part of the normal chain.
I'm presently working on a script that aims to be a brute force attempt at creating the absolute smallest image files, losslessly. So far I have plans for jpeg (optimizing huffman tables) and pngs, might tack on zip optimization or whatnot. It's modular enough... Going to be neat when it's done. Catch all drag and drop, ignores files that aren't supported, processes all that are.
Highly doubt. Like most editing software it probably just uses some quick heuristic that makes decently small files, but not among the smallest.
But I don't know, oughta just test. Here, we'll both take this file, process it, and see which is smaller. Might take a moment to process for me, I'm doing a few things at once.
PNG is my favourite Raster Image format
SVG for muh vectors
lossy formats are for cunts
42.27% smaller with a default parameter run of optipng 0.7.4
~54% reduction. Script (pngslim) uses a combination of optipng, pngout, and zopfli, last I remember anyway. It has changed somewhat.
Hold on. I'm doing another test.
43.06% smaller with pngcrush -bail -brute -fix -rem allb -reduce
Do I want my jpgs progressive and my pngs interlaced?
Isn't that just about how they load on the web?
>Isn't that just about how they load on the web?
short answer: yes
if you're dealing with different people's views on what's most optimized and lossless then it has differences in dealing with that as well as if you assume people are on even slower connections
>Progressive JPEG & non-interlaced PNG is best.
I agree with this man
welcome to the horrible horrid world of images being supported on multiple formats in multiple systems
welcome to hell
also welcome to the horrible world in which an image isn't guaranteed to look the same because of how software interprets it
welcome to hell T_T
I do find humor in using things other people have 'cast aside'
Interesting; optipng -fix -strip all -i0 -zc1-9 -zm1-9 -zs0-3 -f0-5
Produces the same size file.
Here's my old derpy program I had after quite a bit of research
It uses almost all different stuff from pngslim
considering this is 2+ years out of date and the pngslim guy works on his constantly I feel pretty good still, especially because for awhile when he started I was still better than him
I guess I'd like to pass it on to an American and not that frenchfag who thinks he's so great when he isn't
here's the tl;dr version
png for lossless images or tiny lossless graphics
jpg for bigger pics where you can sometimes lose a little quality and most people won't notice it
gif for tiny graphics besides animation and for things in certain color palettes you want larger
jpg for photos and shit like that
png for images with large areas of the same color (screenshots from chinese cartoons, vectors, etc)
gif can be used for the same shit as png, only it's limited to 256 colors
pic related, would be bigger and shittier to read as a jpg
never use jpg for images with text (will become unreadable)
never use png for photos (will become xboxhueg)
-Use GIF when your image is small and uses less than 256 colors
-Use jpeg when perfect reconstruction of the source file is unnecessary, it has high complexity / "frequency (energy)" composition, and when resolution is simultaneously too high for lossless to be viable. Ideally, you can ignore all the above specifics about frequency and energy, and most of the technical specifics of DCT compression / quantization. Use jpegs only when the detriment does not outweigh the benefit. If your image is all solid colors, or you're seeing compression artifacts, you're doing it wrong.
-png. ALWAYS use when your image is mostly solid colors. Always. There is nothing more irritating than a 10mb jpg to code for something that could be lossless and 500 kb as a png. Very few gradients is typically good. Limited color palette (black and white) is good for pngs. And anything you don't want to lose quality. It really varies, and as time goes on you'll start to get a natural feel for what is what. I don't like lossy stuff, so I'll almost always use pngs unless there's a good reason NOT to. Not the inverse. jpg shouldn't be treated as a defalt go to format. It isn't. Nothing lossy ever is.
I chose a grainy screen with varying contrast and shapes from a lossy source with typical compression artifacts on purpose. It represents a typical use case, and a few of the main factors that play into png compression (thus accurately testing whatever application is trying to compress further).
At 30 mb/s though, any artifacting isn't really all that meaningful, it's close enough to how the source is, probably (aside from some mosquito noise in certain scenes).
>4chan thinks it's spam
Maybe you should... post it as a png.
if anything these fucked up images give a better standard for png compression values since the gap between sizes is wider
testing on a smaller or "higher" quality image either with a lower palette or less "fuzz" alot of times can result in the same image size through multiple tests or files that are not bytes apart but only bits apart
I'd love to talk with you about this more in the thread, however I can't stick around in the thread much longer, email would provide more long term regular contact if you wish to hear my experience in this realm
There's not really alot of people online that get very serious into this sort of thing, mainly because it's time consuming besides consuming on CPU, and most people these days just say to throw more bandwidth at the issue rather than work on it
>It represents a typical use case
But it's definitely not what png is for. A better test image would be a screenshot of this thread: mostly text, lots of flat colors, but still contains hard to compress parts
Just a tad bigger than PNG in lossless mode, and half the size of JPEG for the same quality.
>inb4 hur dur MS format
Unlike H.264 that everyone uses without complains, MS is using a BSD licence for it.
You people do realize that different formats have different strengths and weaknesses, right? Using PNG for something like a photo is a terrible idea for example.
I really like the idea of WebP, but nobody uses it so I can't tell if it's the holy grail of image formats like it says it is.
>Why is it PNG?
Not even close. PNG takes a compression algorithm designed for text and tries to apply it to image data. It's pretty convincingly beaten by modern formats like WebP. We need to replace GIF, JPEG and PNG with modern formats.
Sorry, I don't give out my email and have lost track of any secondary emails I've ever had. At a point in my life I grew away from making any lasting contacts, and despite myself, life, and my environment all changing quite a lot, a good deal tends towards being the same as it ever was.
It's true, not a lot of people seem to take compression very seriously. Honestly, there hasn't really been any legitimate new development in lossless compression for some number of years. Part of me in the back of my mind has been putting together a lossless compression scheme, first intended solely for 720x480 limited range YCbCr 4:2:0 video, then slowly expanded out to all types of data. Maybe something will come of it, or maybe just lack of sleep talking.
Deflate wasn't designed just for text, as far as I know. Neither were most of the other parts o the PNG spec.
Though I agree with the essence of what you're saying. Modern compression could be much faster and more efficient.
I think it would work fairly well with only a few key players on board.
Microsoft (because native Windows support).
Wikimedia (including them because I think they would be on board and they serve a lot of images).
Google (already supports it everywhere???)
7 key players (if you include 4chan, 6 otherwise) and all of a sudden WebP would become a huge success.
Without a method of contact you'll have a hard time learning from others, I'm outta the thread for now, if it's still up in 8 hours I'll check again though
I'll give you a hint though, it's not just the compression methods used but the orders they're used in as well, even repeating the same process after used on another
I was thinking also of the programmers and technical developers that need to be on board as well if you want to finally get away from old image formats all at once
hell this even means(to me at least) images inside firmware and imbedded applications and such
only looking at images as a webstandard is narrow minded ~_~
Yeah, it sucks that it hasn't happened yet. I don't think it will be too difficult though. Like >>45688363 says, it just needs the right people on board. The current situation is shit because different web browsers can't agree on which format to use, but if Microsoft, Apple, Mozilla and Google all decided on one (patent free) format, it might be possible.
What? Yeah it does. Otherwise PNG files would be as large as BMPs. You might be confusing lossy with lossless compression.
I always thought it was. You're probably right.
Does PNG support all the various kinds of metadata JPEG supports? For example camera model, exposure time, ISO, focal length and so on?
I don't think it does. Oh and photos becomes huge in PNG.
Yes that's correct in the broad sense.
The more complex the image is (in terms of colors and such), the more likely it is that JPEG is more suitable.
JPEG hates text so it's not that great to use for that. (For example if you got white text on a black background).
PNG is good for either fine gradient (because JPEG will butcher that) but the file will be big.
PNG is also good for clean lines as well as big areas with the same color.
Reduced by ~300kb.
As far as I'm aware, the tEXt chunks can be used to represent arbitrary information.
>As far as I'm aware, the tEXt chunks can be used to represent arbitrary information.
Wouldn't that be a disaster in terms of program support though? You'd have to make a brand new standard on how to format all the different variables in the tEXt field, or else programs wouldn't know how to interpret it.
Sure it's possible but not as elegant of a solution as JPEG.
Well, most programs where that kind of information matters likely have manual ways to set it, and at least the information would still be present and readable. Even if it's less convenient.
An inclined programmer working on one of these applications could probably write some logic to parse through those chunks and find data that looks like it's meant to mean a certain thing. It could be fairly accurate, spending. But yes, it's nothing like standardized support.
For screenshots, text heavy images, very sharp minimal colour images I will go with PNG
For pictures/photographs or anything with details that do not need to be super precise I will go with JPG
For animated images GIF and webm. Obviously webm preferred but GIF is far better supported.
Why for screenshots? That's situational for me. For things like game screenshots I use JPEG. Same with screenshots from movies and anime. If I take a screenshot of a website like this thread then it's PNG.
Sure if you want it EVERYWHERE then it will take a lot of time. I would be totally okay with it being a big image format on the web though.
>What? Yeah it does. Otherwise PNG files would be as large as BMPs. You might be confusing lossy with lossless compression.
It applies the compression to something else. Read the wiki link posted already. PNG applies compression to processed image data.
What? PNG is compressed. Compressed does not mean lossy though. FLAC is also compressed, but not lossless. That's why PNG is smaller than BMP.
BMP saves all the data for every single pixel in the image, and is therefore not compressed.
A 500x500 BMP image is just as big as a really complex 500x500 photo saved as BMP.
If you save the completely white image as PNG it will just contain the info needed to say "the whole image is white", and therefore be much smaller. It doesn't go "pixel 1 is white, pixel 2 is white, pixel 3 is white" like BMP does.
Can you please reformulate that sentence because I have no idea what you mean.
Of course the image data is compressed. How do you think it makes a file that would be ~5MB in uncompressed format become like 1MB? The meta data is not that big.
That sounds cool. Does it support transparency as well?
>Very few gradients is typically good
PNG is actually designed to handle gradients well. It's just that Photoshop adds dithering to gradients by default and that doesn't compress well.
It still compresses the "image data". It's just that it runs some precompression filter on the data first. It's still the image being compressed.
Sure it doesn't just run the compression algorithm on the image and then it's done, but it still compresses the image.
If you look at post that stated this, >>45688299, my response is perfectly fitting. PNG applies compression algorithm to data well-suited for use with this compression algorithm.