Image Formats

I don't have a favorite image format. I like other things.

>>45686140
TIF 4 LYFE

>>45686140
definetly png

JPEG2000

If you're not optimizing your .PNGs with something like OptiPNG, pngcrush, or PNGOUT then you can get fukt.

Can anyone explain which answer respects my freedom the most?

File: 42.gif (42B, 1x1px) Image search: [Google]

42B, 1x1px

I bet you can't post a PNG with a smaller file size.

>>45686255
you're right, whatever can I do with my image taking up a whole 68 bytes?

>>45686255
I bet you can;t post a better quality image with a smaller size.

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

>>45686219
Those are horrible.

PSP7 has the best PNG optimizer out there.

>>45686249
>PNG
Designed to be patent free from the start and ending up being superior to the format it was designed to replace, GIF

File: Ghost in the Shell.mkv_snapshot_00.07.35_[2014.10.17_22.54.13].png (4MB, 1920x1080px) Image search: [Google]

4MB, 1920x1080px

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

>>45686361
>30 bytes for a single pixel.

psd

HDR/EXR master race

File: 1399990575864.png (42KB, 362x362px) Image search: [Google]

42KB, 362x362px

PNG is my favourite Raster Image format
SVG for muh vectors

lossy formats are for cunts

File: 1418975709217.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

>>45686419
42.27% smaller with a default parameter run of optipng 0.7.4

BPG Master Race.

File: Ghost in the Shell.mkv_snapshot_00.07.35_[2014.10.17_22.54.13].png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

>>45686524
~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.

File: pngcrush.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

>>45686524
43.06% smaller with pngcrush -bail -brute -fix -rem allb -reduce

File: pngout.png (3MB, 1920x1080px) Image search: [Google]

3MB, 1920x1080px

>>45686768
PNGOUT a shit.

>>45686800
I just use this

http://www.voralent.com/products/antelope/

>>45686140
if you use png correctly its efficient. I hate all those fags that think they have to use it for everything.

File: 141897hhhhh5709217.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

>>45686811
Larger file size though.

>>45686821
I use it for all my image needs.

>>45686832
faggot

>>45686832
you're the cancer of the internet.

>not using what is best for the task at hand

>>45686329
welcome to being me from 5 years ago

the amount of time you can spend on this is ridiculous

respond to this post if you wish to talk at all

File: antelope.png (5KB, 283x242px) Image search: [Google]

5KB, 283x242px

>>45686946
Do I want my jpgs progressive and my pngs interlaced?

Isn't that just about how they load on the web?

TGA

>>45686970
Progressive JPEG & non-interlaced PNG is best.

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

>>45686983
>Progressive JPEG & non-interlaced PNG is best.
I agree with this man

When will webP or something take over?

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

>>45687016
fuck that, I want an image format based on Daala when Daala is done

File: a.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

kek

advpng

I do find humor in using things other people have 'cast aside'

File: pngo.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

>>45686768
Interesting; optipng -fix -strip all -i0 -zc1-9 -zm1-9 -zs0-3 -f0-5
Produces the same size file.

File: derp.png (2MB, 1920x1080px) Image search: [Google]

2MB, 1920x1080px

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

ok fags, when do i use png and when do i use jpg? also is there a single use for gif that isnt animation?

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

File: 1418000019538.png (36KB, 219x171px) Image search: [Google]

36KB, 219x171px

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

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

>>45687695
>Use jpegs only when the detriment does not outweigh the benefit.
Ugh, what did I even write here. I think you know what I mean though.

>>45686419
>>45686524
>>45686599
>>45686768
>>45686800
>>45686830
>>45687310
>>45687562
>>45687606
cool to see /g/ actually empirically testing stuff

>>45687639
Also, .png for text. Perfect for screenshots too.

>>45686419
>using a grainy image from a lossy video to test png compression
Imagemagick with

-quality 98

gives a 617kB jpg, but 4chan thinks it's spam and won't let me post it.

File: jaypeg.jpg (602KB, 1920x1080px) Image search: [Google]

602KB, 1920x1080px

testing without the rest of the post

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

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

>>45687936
>I chose
are you the one who originally posted:
>>45686329
>I'm presently working on a script

if so post your email please, or if you're interested in this more anyway

>>45687999
>are you the one who originally posted:
I am. I left the thread for a while though.

I'd be interested to talk about it a bit.

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

PNG and EMF

muh vector graphics

File: thread.png (3MB, 1910x8460px) Image search: [Google]

3MB, 1910x8460px

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

>>45686140
JPEG-XR
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.

>>45688101
not the poster you're responding to, but damn

that image is so huge, want the comp to take a dump compressing that?
I would say that test image is guaranteed way way too big

>>45688110
I had to use pngcrush and optipng to post it, it doesn't take that long to compress.

File: Webp_-_Jpeg_-_Lossless_comparative.png (3MB, 2412x1500px) Image search: [Google]

3MB, 2412x1500px

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.

i like bmp

>>45688154
webp is good, the support isnt there though

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

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

>>45688299
I agree with you

do you know what a huge task that is though?

like absolutely immense task?

>>45688299
PNG does not apply compression to image data.

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

>>45688326
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).
Tumblr
Google (already supports it everywhere???)
4chan
Imgur
Facebook

7 key players (if you include 4chan, 6 otherwise) and all of a sudden WebP would become a huge success.

Where are my lossless 500KB WebP images rivaling 3MB PNG images!

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

JPG fags, give me ONE good reason why I should EVER use JPG instead of PNG

>>45688363
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 ~_~

I always thought you should use PNG for drawn images and JPEG for photographs.

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

>>45688336
What? Yeah it does. Otherwise PNG files would be as large as BMPs. You might be confusing lossy with lossless compression.

>>45688357
I always thought it was. You're probably right.

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

>>45688414
Some reading you might find interesting.
http://en.wikipedia.org/wiki/Portable_Network_Graphics#Compression

>>45688431
DEFLATE wasn't invented for PNG though.

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

File: 1418990054591.png (2MB, 1910x8460px) Image search: [Google]

2MB, 1910x8460px

>>45688101
Reduced by ~300kb.

>>45688430
http://en.wikipedia.org/wiki/Portable_Network_Graphics#Ancillary_chunks
As far as I'm aware, the tEXt chunks can be used to represent arbitrary information.

>>45688430
not the guy youre responding to

but if wanted to it could easily hold that metadata in chunks

i think chunks in png files are a cool idea anyway, you should check em out

>>45686140
RAW
AWR in my case

>>45688474
*ARW

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

>>45688495
more likely png committee could just add new ancillary chunk types if that was desired

kind of a moot point though since png wasnt designed for that type of photographic imagery

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

>>45688529
spending = depending*

>>45686970
I read many tutorials on pics compression that said progressive jpeg are often a tiny bit smaller.

.PSD

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

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


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

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

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

Bumping for further discussion potential.

>>45689161
PNG does not apply compression to image data.

BPG. You know it's some serious shit if phys.org does an article on it.

>http://phys.org/news/2014-12-bpg-image-format-awesome-jpeg.html

>>45690464
Y'know it would be great if BPG replaced JPEG, but it's going to take forever to become the new standard. Just like pretty much everyone still uses MP3 even though Opus exists.

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

>>45690464
That sounds cool. Does it support transparency as well?

>>45690633
PNG compresses the data that is obtained by filtering the image. Unlike GIF, which compreses image data directly.

>>45690464
What about licensing?

>>45687695
>-Use GIF when your image is small and uses less than 256 colors
Why not PNG with fixed palette?

>>45686490
https://0.t.4cdn.org/g/1418976028752s.jpg

>>45690847
Depends on the content. Sometimes png is larger, even if it's only using an 8bit palette.

Lower than 8 bit, png is definitely almost always more efficient though.

File: no-dither.png (113KB, 2000x2000px) Image search: [Google]

113KB, 2000x2000px

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

File: big.gif (30B, 10000x10000px) Image search: [Google]

30B, 10000x10000px

>>45686361
>>45686432

File: dither.png (2MB, 2000x2000px) Image search: [Google]

2MB, 2000x2000px

>>45690974

Png/bng....or for the family photos I care not about jpeg.

Lossy vs lossless kids. Know when to use which

>>45691257
ok kid

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

>>45691399
After you filter it, it's not image data anymore. It's just data. it looks nothing like image.

>>45691409
OK got it. So you were just being extremely pedantic.

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

>>45691559
Oh right. Didn't think the conversation went that far back.
I'm sorry, you're right.

>>45688103
H.264 is a specification and not a piece of software with a copyright license so what you said makes zero sense.

>>45691651
H.264 is a specification with a copyright license. You literally are not allowed to sell software that implements h264 without paying royalties.

>>45686219
usb0r photoshop enough?

>>45686140
SVG, PNG in that order.

>>45690992
BTFO