Requested feature overview description.
WebP is an image format that can compress images more efficiently than JPEG .
Why would it be useful?
Original WebP files can be uploaded instead of converting those to JPEG (and adding generation loss) or PNG (and making those oversized). In order to keep compatibility with older hardware and software i suggest using JPEG downscaled previews as default.
What part(s) of the site page(s) are affected?
Upload, Show.

Is there any examples of where creators are already using this format?

Only places where I have seen this in use are Twitter on mobile, but there it converts the it from PNG or JPG source and Discord for avatars which aren't exactly relevant for us.

Mairo said:
Is there any examples of where creators are already using this format?

Only places where I have seen this in use are Twitter on mobile, but there it converts the it from PNG or JPG source and Discord for avatars which aren't exactly relevant for us.

Currently i do not know any, but someone may want to upload something in WebP format.

Hello, I am an artist would love to be using a format that is significantly more efficient than png or jpegs and it genuinely baffles me that no damned services are interested in updating to this (now decade old) format like they did with the notably superior WebM. God help me if the reason is 'well we don't see the other art sites using it so why should we?'.
I mean, I am sitting here ready and willing to help save both e621 and it's users 20-50% of image database and transfer size. Would be grand.

Really, I'd like to hear from a dev why it isn't happening.

Addendum; I am aware some early 2000s devices aren't supporting this format, but they aren't doing WebM either as far as I am aware, so that can't really be then reason.

It wasn't supported by two of the three major browsers until the end of 2020, and you're the first content creator to ask about support for it and actually has images sitting around waiting to encode in the format. Most art tools don't have an export option for the format, so it would involve exporting copies as PNG and then recompressing them using a tool as webp, and we'd rather have the png at that point(e6 doesn't really care about storage size on original copies of things, it cares about quality). The format is a mess and has a ton of edge cases, and the internal stack doesn't support the format, and adding support for it seems annoying, and potentially time consuming.

On top of this, the format is marked as deprecated, and AVIF or JPEG XL are supposed to replace it, whenever that format war subsides. AVIF suffers the same situation as webp, where there is no tooling surrounding it for artist tools, and browser support is iffy.

kiranoot said:
It wasn't supported by two of the three major browsers until the end of 2020, and you're the first content creator to ask about support for it and actually has images sitting around waiting to encode in the format. Most art tools don't have an export option for the format, so it would involve exporting copies as PNG and then recompressing them using a tool as webp, and we'd rather have the png at that point(e6 doesn't really care about storage size on original copies of things, it cares about quality). The format is a mess and has a ton of edge cases, and the internal stack doesn't support the format, and adding support for it seems annoying, and potentially time consuming.

On top of this, the format is marked as deprecated, and AVIF or JPEG XL are supposed to replace it, whenever that format war subsides. AVIF suffers the same situation as webp, where there is no tooling surrounding it for artist tools, and browser support is iffy.

https://www.gimp.org/news/2020/10/07/gimp-2-10-22-released/
https://www.phoronix.com/scan.php?page=news_item&px=Firefox-Enables-AVIF-Default

AVIF support has been increasing in recent months, and Google will push it. I would be surprised if JPEG XL caught on.

Most images should be drawn and uploaded as PNG though. Pixel perfect, no compression artifacts.

I've had a webp plugin for Photoshop CS6 for quite some time and since I go from CSP>PS to export pictures in the first place it's never been an issue for me personally. My problems have just been finding services that will accept them, though I can't recall ever having issues viewing them in either Chrome(ium) or Firefox.

In any case I resaved a picture of mine a couple of days ago just measure and it went from 666KB as a png to 405 as a lossless webp, or 304 at 98 quality. My jpeg exports scale about as well into webp. Incidentally I also found a picture in my collection that was FIFTY-SEVEN MEGABYTES because apparently some artists think their sketch of duckmen porking with both film grain and chromatic abberation slapped on has to be published as a fullsize poster print resolution raw unoptimised PNG. And there are so many like it; cases where I've shrunk a file by upwards 800% just by changing the format. It's not my datacenter, but holy shit... Just the browsing of this site's content would be so much better if you enforced some guidelines about filesize and formatting. Even on desktop with first class scandi internet it can be annoying, but it becomes offensive when I'm on a mobile connection.

If it comes down to filesize, please utilize something like Pingo (JPG, PNG, APNG, WebP) (and remember to donate) or PNGGauntlet (PNG) before doing comparison.

Also yeah, couple additional problems with WebP files are that you cannot tell if it's lossy or lossless where if PNG happens to be lossily optimized it's immidiately visible and JPG can never be lossless. Another is that WebP is stuck with VP8 standard which has been obsolete with WebM files for literal years now.

AVIF is apparently going to be the saving grace, but we are back again with original problem.

One thing WebP would be amazing is samples, because of much higher quality compared to JPG with same filesize and transparency support, but even mediawiki generates WebP images thumbnails as PNG, because of the support not being 100%, so we would need to generate two samples instead of one for every image here.

snowskau said:
Just the browsing of this site's content would be so much better if you enforced some guidelines about filesize and formatting.

File size is a non-issue with the reduced samples on, which I believe was made default for everyone.

File size is a non-issue with the reduced samples on, which I believe was made default for everyone.

As someone who likes to keep a local repository I might be more incensed that most about really bad format usage. I've noticed a decent amount of the photoreference I've been collecting lately off of places like wikipedia or other sites through google have been in webp and it's been incredibly useful to me since a lot of these are full size and stand far above the atrociously compressed jpegs I also end up with.

mairo said:
If it comes down to filesize, please utilize something like Pingo (JPG, PNG, APNG, WebP) (and remember to donate) or PNGGauntlet (PNG) before doing comparison.

I shall endeavor to share these utilities, thanks, and I suppose I'll just have to hope avif doesn't go the way of webp.

mairo said:
Also yeah, couple additional problems with WebP files are that you cannot tell if it's lossy or lossless where if PNG happens to be lossily optimized it's immidiately visible and JPG can never be lossless. Another is that WebP is stuck with VP8 standard which has been obsolete with WebM files for literal years now.

AVIF is apparently going to be the saving grace, but we are back again with original problem.

I just checked the Wikipedia article and found this interesting tidbit:

WebP 2 is a newer generation of WebP under development by Google as of June 2021. Its reference implementation is libwebp2. The main goal of this new format is to reach similar compression ratios as AVIF while remaining faster to encode and decode.

I'm also interested in WEBP support. Both for animated and non-animated images. It's a superior format to PNG.

so long as webp doesn't require an internet connection to open like webm (i think) has to, then i don't mind support. since from what i heard support is webp's biggest disadvantage rn

edit: i checked to see if webm needs wifi to open immediatly after writing this post.

i now know that webm doesn't need an internet connection to open, i just assumed that since my web browser could open them meant that you need web browsers ergo an internet connection to access them

dripen_arn said:
now know that webm doesn't need an internet connection to open, i just assumed that since my web browser could open them meant that you need web browsers ergo an internet connection to access them

You don't even need an internet connection to use a web browser.

Have there been any updates regarding WebP support? I've been finding images using it and it would be convenient to be able to upload.

Can we please get WebP support? For lossless, WebP provides much better compression than PNG. For lossy, WebP looks way better than JPG for the same file size.

aaronfranke said:
Can we please get WebP support? For lossless, WebP provides much better compression than PNG. For lossy, WebP looks way better than JPG for the same file size.

I'd like to see JPEG XL for the same reason. Better lossless support than webp, and even better lossy compression. It also supports animations, alpha, and salience mapping (essentially marking certain areas of the image as more important so it loads the details for important areas first, making for a perceptually faster image loading as you don't need to have as much of the file loaded to clearly see the more important parts). You can even convert existing JPG files to JPEG-XL for up to 20% size reduction with no change in visual quality, and a JPG->JPEG XL converted file can be converted back to JPG without introducing more noise.

Unfortunately Google wants to push the inferior AVIF format instead, and given Google's monopoly, they hold the cards. Most browsers either support it (Safari, Thorium, Pale Moon, Waterfox), or can support it (Firefox has it behind a build flag currently, but add-ons are available for Firefox and Chrome). But Chrome and Chrome-derivatives (Edge, Opera) are more troublesome, which holds back adoption. Web monopolies suck.

JPEG XL has non-existent browser support, so it can't be considered yet, unfortunate given how good of a standard it is.

AVIF would be great to have but support is not as widespread as WebP, it looks like it's not supported in Edge and Opera Mini yet, and GIMP can't export a lossless AVIF (only "nearly lossless"). That said I would vote in favor of AVIF support too. EDIT: I just gave it a test, GIMP's "nearly lossless" AVIF is actually larger in file size than lossless WebP.

WebP has nearly universal support in web browsers, image editors, and other tools, and it has significant benefits over JPG and PNG.

Three conflicting sides of my geekiness on this one:

As an amateur web dev, WebP is a useful format that’s already been implemented on many major sites (Reddit comes to mind first) without much issue. Fewer megabytes per image = more server space and faster download times for users on slower connections.

As an artist, it’s not too much of a pain to export as .webp to help the server and its visitors. My main art software (Procreate) supports it natively, and for pixel art (GrafX2), I can always shift from .png to .webp in Paint.NET or a similar software (Krita, GIMP, Photoshop Elements 8, etc.)

As a user, I do not like WebP and WebM. Why?
I still use an old Windows 7 laptop and Windows XP fairly often. I have a bog-standard installation of Win10 Pro on an old enterprise machine that I never connect to the ‘net. Surprise! Only the Win10 machine can even open the image — and even then, it opens it in Edge instead of a proper image viewer. Could I get over the inconvenience? Probably. But having to bulk convert 100+ WebP files just to use them on an old computer that still works drives me a little batty from time to time.

Perhaps the real question is “is the standard here to stay.” PNG has survived for decades along with JPEG. GIF, though old and superseded, is still useful. That’s about it for “old standards” now. When was the last time you tried to open a .BMP or .IFF, anyway? (Rhetorical question. Retro geeks, please leave me alone. I opened one yesterday.)

TL;DR Hi-res PNG should still be the standard, but WebP support would be nice.

I think new format requests will be ignored as long as artists or the sites they are uploading to aren't adopting them.

WebP is very common these days, but practically no artists are going to save to it knowingly.

If art sites are encoding uploads as WebP or AVIF, please mention them.

lance_armstrong said:
I think new format requests will be ignored as long as artists or the sites they are uploading to aren't adopting them.

WebP is very common these days, but practically no artists are going to save to it knowingly.

If art sites are encoding uploads as WebP or AVIF, please mention them.

I found an image solely in WebP that I couldn't find elsewhere. I didn't want to do a lossy>lossy conversion, either. That said, most people likely wouldn't consider it to be a huge loss.

I can really only speak to audio and video standards.

watsit said:
I'd like to see JPEG XL for the same reason. Better lossless support than webp, and even better lossy compression. It also supports animations, alpha, and salience mapping (essentially marking certain areas of the image as more important so it loads the details for important areas first, making for a perceptually faster image loading as you don't need to have as much of the file loaded to clearly see the more important parts). You can even convert existing JPG files to JPEG-XL for up to 20% size reduction with no change in visual quality, and a JPG->JPEG XL converted file can be converted back to JPG without introducing more noise.

Unfortunately Google wants to push the inferior AVIF format instead, and given Google's monopoly, they hold the cards. Most browsers either support it (Safari, Thorium, Pale Moon, Waterfox), or can support it (Firefox has it behind a build flag currently, but add-ons are available for Firefox and Chrome). But Chrome and Chrome-derivatives (Edge, Opera) are more troublesome, which holds back adoption. Web monopolies suck.

Uhm, if enough image gallery sites use it, it'll be much more likely that Chrome will get it? This is how we got PNG in the first place, right?

aaronfranke said:
JPEG XL has non-existent browser support, so it can't be considered yet, unfortunate given how good of a standard it is.

AVIF would be great to have but support is not as widespread as WebP, it looks like it's not supported in Edge and Opera Mini yet, and GIMP can't export a lossless AVIF (only "nearly lossless"). That said I would vote in favor of AVIF support too. EDIT: I just gave it a test, GIMP's "nearly lossless" AVIF is actually larger in file size than lossless WebP.

WebP has nearly universal support in web browsers, image editors, and other tools, and it has significant benefits over JPG and PNG.

Yeah, WebP is a no-brainer. AVIF and JEPG XL not so much. There's a reason that containers for web videos are TS or the like and not ASF or whatever stupid thing Microsoft owns.

eqp said:
Three conflicting sides of my geekiness on this one:

As an amateur web dev, WebP is a useful format that’s already been implemented on many major sites (Reddit comes to mind first) without much issue. Fewer megabytes per image = more server space and faster download times for users on slower connections.

As an artist, it’s not too much of a pain to export as .webp to help the server and its visitors. My main art software (Procreate) supports it natively, and for pixel art (GrafX2), I can always shift from .png to .webp in Paint.NET or a similar software (Krita, GIMP, Photoshop Elements 8, etc.)

As a user, I do not like WebP and WebM. Why?
I still use an old Windows 7 laptop and Windows XP fairly often. I have a bog-standard installation of Win10 Pro on an old enterprise machine that I never connect to the ‘net. Surprise! Only the Win10 machine can even open the image — and even then, it opens it in Edge instead of a proper image viewer. Could I get over the inconvenience? Probably. But having to bulk convert 100+ WebP files just to use them on an old computer that still works drives me a little batty from time to time.

Perhaps the real question is “is the standard here to stay.” PNG has survived for decades along with JPEG. GIF, though old and superseded, is still useful. That’s about it for “old standards” now. When was the last time you tried to open a .BMP or .IFF, anyway? (Rhetorical question. Retro geeks, please leave me alone. I opened one yesterday.)

TL;DR Hi-res PNG should still be the standard, but WebP support would be nice.

Dude, install irfanView or the like. It's not really the OS's place to support Every File Format. Even when Windows does, it sucks at it. ZIP 2.0 in this century? XD While you're at it, SumatraPDF and Calibre, if you read fanfics/novels.

LOL, BMP and WAV would only be supported because they're the "Hello, World" of file loading/saving, anyways. i.e. Use them to sanity check the actually used formats.

lance_armstrong said:
I think new format requests will be ignored as long as artists or the sites they are uploading to aren't adopting them.

WebP is very common these days, but practically no artists are going to save to it knowingly.

If art sites are encoding uploads as WebP or AVIF, please mention them.

Chicken and egg. Yeah, no incentive to post them here in the first place, and if there's no support here, they'll just have to convert it to PNG/JPEG and so the circle goes.

peacethroughpower said:
I found an image solely in WebP that I couldn't find elsewhere. I didn't want to do a lossy>lossy conversion, either. That said, most people likely wouldn't consider it to be a huge loss.

I can really only speak to audio and video standards.

If most browsers support it, seems weird not to just allow it. Yeah, I ran into this issue with VFR Ugoira support. Even if I can just create a variable-framerate video file from the ZIPs I got off of Pixiv, I can't upload them without basically defeating the point. It's not supported CODEC options. Mairo, me, and others have been talking about this for a while, now. Apparently, 'some devices' refuse to handle VFR properly. Same as 'some devices' crash if they see MP3 tags in a FLAC file or the like (What.CD used to have a rule against that before getting raided). You couldn't do software updates like you can with more modern players or software players to add support. There are still some devices that use hardware-based decoding that simply can't keep up using the 'slow path' (CPU).

alphamule said:
Uhm, if enough image gallery sites use it, it'll be much more likely that Chrome will get it? This is how we got PNG in the first place, right?

Yeah, WebP is a no-brainer. AVIF and JEPG XL not so much. There's a reason that containers for web videos are TS or the like and not ASF or whatever stupid thing Microsoft owns.

Dude, install irfanView or the like. It's not really the OS's place to support Every File Format. Even when Windows does, it sucks at it. ZIP 2.0 in this century? XD While you're at it, SumatraPDF and Calibre, if you read fanfics/novels.

If most browsers support it, seems weird not to just allow it. Yeah, I ran into this issue with VFR Ugoira support. Even if I can just create a variable-framerate video file from the ZIPs I got off of Pixiv, I can't upload them without basically defeating the point. It's not supported CODEC options. Mairo, me, and others have been talking about this for a while, now. Apparently, 'some devices' refuse to handle VFR properly. Same as 'some devices' crash if they see MP3 tags in a FLAC file or the like (What.CD used to have a rule against that before getting raided). You couldn't do software updates like you can with more modern players or software players to add support. There are still some devices that use hardware-based decoding that simply can't keep up using the 'slow path' (CPU).

I'm just glad FLAC and Opus are supported by everything. They're the best lossless and lossy audio formats out there by far.

Second the recommendations on Irfanview and SumatraPDF.

I remember my first gaming computer had an i3-3220, later upgraded to an i7-3770k. It couldn't play x265, so I could only legitimately purchase x264 encodes.

After 3 years, WebP has become a lot more supported format and used on tons of websites nowdays.
I'm not sure about file upload format, but for thumbnails and samples, we should already have this, higher resolution and quality for lower filesize than 85 quality JPG.

I'd caution against allowing WebP uploads purely because of the easy scaling it seems to provide and that Firefox always seems to download that scaled version. It's a pain in the ass for me to confirm I've downloaded the original size WebP from other sites (and to check for a non-WebP version), so I imagine regular users don't stand a chance of finding full quality WebP's to post here. As an e621 user, I don't think I'd be bothered if e621 starts using WebP as long as the Download button for the original file remains easy to find.

abadbird said:
I'd caution against allowing WebP uploads purely because of the easy scaling it seems to provide and that Firefox always seems to download that scaled version. It's a pain in the ass for me to confirm I've downloaded the original size WebP from other sites (and to check for a non-WebP version), so I imagine regular users don't stand a chance of finding full quality WebP's to post here. As an e621 user, I don't think I'd be bothered if e621 starts using WebP as long as the Download button for the original file remains easy to find.

I was wanting to add some more sites to the URL source whitelist for this reason... Some methods exist that can 'fix' certain URLs. They'd fix it before you upload it because they would be able to change the URL to the better version. For uploading files from your local machine, tools like Raccoony and Pixiv Toolkit take a lot of the guesswork out of getting the 'right' image. They also give you metadata you can use for organizing them.

https://e621.net/forum_topics/26402?page=1#forum_post_290711 Old post about getting specific versions of a file.

alphamule said:
Dude, install irfanView or the like. <snip> While you're at it, SumatraPDF and Calibre, if you read fanfics/novels.

OT: Just installed IrfanView and set it as my new default viewer. WebP no longer scares me. Thanks for the recommendation. :-)
(I mostly read books in "dead tree" format, so I don't have much use for Calibre, but SumatraPDF looks interesting.)

abadbird said:
As an e621 user, I don't think I'd be bothered if e621 starts using WebP as long as the Download button for the original file remains easy to find.

That sounds like a better idea than what I had in mind. Having two download buttons (one for .webp and one for the original file) would be nice.

eqp said:
OT: Just installed IrfanView and set it as my new default viewer. WebP no longer scares me. Thanks for the recommendation. :-)
(I mostly read books in "dead tree" format, so I don't have much use for Calibre, but SumatraPDF looks interesting.)

That sounds like a better idea than what I had in mind. Having two download buttons (one for .webp and one for the original file) would be nice.

IrfanView isn't the only one, but it's well-known because it just... works with most files ala VLC and 7Z. The filter tools aren't too bad, either. It also can be made to run Flash files.
Oh, yeah, as a viewer of EPUBs, SumutraPDF's great. I changed these options in advanced configuration to get a more readable view. White text on black backgrounds for us not-quite-blind-yet people. ;)

MainWindowBackground = #ffffff00
UseSysColors = false

FixedPageUI [
	TextColor = #ffffff
	BackgroundColor = #000000
	SelectionColor = #f5fc0c
]
EbookUI [
	FontName = Arial
	FontSize = 14
	TextColor = #ffffff
	BackgroundColor = #000000
]

Well, might want to not make it confusing. Having the source file on 'download' button has been a stable UI element for a long time here for some good reasons. Offering alternative sources has as well. If someone is unfortunate to have the less compatible device, then an option to offer conversion to PNG for lossless files (as example) using cached converted files makes sense as well. Hilariously, you can use JS to do the conversion at the client side without that cache, right? ;)

lance_armstrong said:
I think new format requests will be ignored as long as artists or the sites they are uploading to aren't adopting them.

I upload a lot of art that I commission artists to make, and I upload art from friends, artists, and others for which I've asked permission to upload their content. It's rare for me to upload the original file as-is. Usually I use oxipng with the Zopfli algorithm to losslessly optimize the image. However, this can take a long time (many minutes to an hour) depending on the size of the image. WebP lossless compression is both faster and uses less space than Zopfli oxipng. So anyway, even if artists don't adopt WebP, I would convert all the PNG files they give me to WebP for improved efficiency.

abadbird said:
I'd caution against allowing WebP uploads purely because of the easy scaling it seems to provide and that Firefox always seems to download that scaled version. It's a pain in the ass for me to confirm I've downloaded the original size WebP from other sites (and to check for a non-WebP version), so I imagine regular users don't stand a chance of finding full quality WebP's to post here. As an e621 user, I don't think I'd be bothered if e621 starts using WebP as long as the Download button for the original file remains easy to find.

Your browser will show you whatever file the web server sends you. So long as e621 does not do any weird scaling, you won't get any scaling. It's the same with JPG and PNG, as long as the server doesn't scale it, it's not scaled.

I would prefer a simpler solution of uploading WebP and downloading WebP, I don't think e621 should be doing automatic file type conversion on the full resolution file. Except for thumbnails and downscaled images, those would make sense to only have in the WebP format.

aaronfranke said:
Your browser will show you whatever file the web server sends you. So long as e621 does not do any weird scaling, you won't get any scaling. It's the same with JPG and PNG, as long as the server doesn't scale it, it's not scaled.

I would prefer a simpler solution of uploading WebP and downloading WebP, I don't think e621 should be doing automatic file type conversion on the full resolution file. Except for thumbnails and downscaled images, those would make sense to only have in the WebP format.

Reminds me of the thing on mobile phones where it rescales them on-the-fly using a proxy, so if you saved them with an iPhone... I wonder if that user is facing that sort of problem. If the browser is saving a resized version of an image, that's a different problem. I don't think I've seen any that do that unless say, to a bitmap because it fell out of browser cache (but it still had decompressed copy in RAM).

aaronfranke said:
I upload a lot of art that I commission artists to make, and I upload art from friends, artists, and others for which I've asked permission to upload their content. It's rare for me to upload the original file as-is. Usually I use oxipng with the Zopfli algorithm to losslessly optimize the image. However, this can take a long time (many minutes to an hour) depending on the size of the image. WebP lossless compression is both faster and uses less space than Zopfli oxipng. So anyway, even if artists don't adopt WebP, I would convert all the PNG files they give me to WebP for improved efficiency.

The website allows up to 100 mb, what your doing is unnecessary. I do not ever compress images I post here and that ensures the image is not altered in a way that makes it bad to upload.

wolfmanfur said:
The website allows up to 100 mb, what your doing is unnecessary. I do not ever compress images I post here and that ensures the image is not altered in a way that makes it bad to upload.

Sounds like they're just using a program that makes better png files (png is always lossless, ie. every pixel will be exactly as it was in the original art, but it's kind of like navigation instrusctions: there's more than one way to get to the exact same place.)

That all said, saving as png instead of something like jpeg ensure that you're not affecting the quality before uploading it.

.. I'm reasonably sure that altering originals, even with no change to image pixel values, is discouraged.
(note that lossless re-encoding of the image pixels doesn't mean other parts of the image will not be removed or abridged. Comment block, EXIF data, ICC data are some examples that I've seen stripped by optimizers)

savageorange said:
.. I'm reasonably sure that altering originals, even with no change to image pixel values, is discouraged.
(note that lossless re-encoding of the image pixels doesn't mean other parts of the image will not be removed or abridged. Comment block, EXIF data, ICC data are some examples that I've seen stripped by optimizers)

I saw a hilarious example from a post roughly a decade old that looking at it in an hex editor, it's almost entirely the same bytes. It was like 10MB for an image that compressed (losslessly) to a lot less than that. I'll have to pull it up. Yeah, not all tools preserve metadata, and not everyone WANTS to preserve it. It also screws up MD5 hashes, which is more annoying if trying to manage sources/indexes.

https://e621.net/posts/142209?q=filesize%3A%3E9mb+-animated+-absurd_res First of many like that. The 'compressed' size is actually bigger than the raw bitmap on this example.

alphamule said:
https://e621.net/posts/142209?q=filesize%3A%3E9mb+-animated+-absurd_res First of many like that. The 'compressed' size is actually bigger than the raw bitmap on this example.

the thing about bitmaps is that they don't have transparency, so you have 24 bit pixels.

just because it's compressed, it doesn't necessitate that it was compressed effectively (ie. resaving this post as png on an app in my phone reduces it to 710KB)

Also, hashes are mainly useful for looking up if an image exists on a website already as it's MUCH faster to check against a list of strings than comparing actual images. Not a necessary thing, but still more important than metadata imo.

magikarp said:
Sounds like they're just using a program that makes better png files (png is always lossless, ie. every pixel will be exactly as it was in the original art, but it's kind of like navigation instrusctions: there's more than one way to get to the exact same place.)

Yes, it's just better PNG files. The same exact pixels, but a smaller file size. I know it's not necessary because the site will allow large files, but it's better because it will load faster, use less disk space / database size / bandwidth, etc.

savageorange said:
.. I'm reasonably sure that altering originals, even with no change to image pixel values, is discouraged.
(note that lossless re-encoding of the image pixels doesn't mean other parts of the image will not be removed or abridged. Comment block, EXIF data, ICC data are some examples that I've seen stripped by optimizers)

It does strip that information, but I never want that information to be saved. Furry art images are not photographs with embedded location data that needs preserving, it's just an image. I only care about its visual data.

As for hashes, yeah that's unfortunate, but there's a lot of situations that would cause the hash to mismatch, such as if you grabbed a reduced resolution image from FurAffinity and tried to find an identical hash on e621 where a full resolution version was uploaded, it won't work. Hashes alone are not and cannot be a reliable way to search for duplicate images, unfortunately.

aaronfranke said:
As for hashes, yeah that's unfortunate, but there's a lot of situations that would cause the hash to mismatch, such as if you grabbed a reduced resolution image from FurAffinity and tried to find an identical hash on e621 where a full resolution version was uploaded, it won't work. Hashes alone are not and cannot be a reliable way to search for duplicate images, unfortunately.

Hashes don't need to be reliable as they are merely a convenience in case someone happens to upload an identical file, but on the flipside, e621 is supposed to host the highest quality published version of an image. Assuming an image is posted elsewhere snd someone tries to repost it here, it would ding the hash check.

Also, back to webp, it also supports lossy compression. Perhaps that could be a concern?

Less tech oriented users saving their work as webp, but with lossy compression. With PNG, the only way to lose image data is to use a program that explicitly modifies it to improve effectiveness with png encoding algorithms before actually putting it through png encoding.

I am interested of the "smaller than png" filesizes you have gotten, have you tested the originals against the webp encoded ones to verify the lossless aspect?

aaronfranke said:
It does strip that information, but I never want that information to be saved. Furry art images are not photographs with embedded location data that needs preserving, it's just an image. I only care about its visual data.

ICC is part of its visual data, so..

MagiKarp

I'm satisfied with my tests of WebP's lossless option, and that it gives 10-20% smaller files pretty consistently.

GIMP for example does default to LOSSY webp export, so I think your scenario of carelessly destroying image pixels is realistic.

I do note that some webp export software may discard RGB information in fully-transparent areas; I haven't tested whether GIMP's does this. With the official CLI tool cwebp you must explicitly request that this information is preserved, by specifying -exact in addition to the baseline -lossless option.

alphamule said:
I saw a hilarious example from a post roughly a decade old that looking at it in an hex editor, it's almost entirely the same bytes. It was like 10MB for an image that compressed (losslessly) to a lot less than that. I'll have to pull it up. Yeah, not all tools preserve metadata, and not everyone WANTS to preserve it. It also screws up MD5 hashes, which is more annoying if trying to manage sources/indexes.

*flashbacks to the 97MB JPEG that turned out to be because the artist had somehow managed to accidentally append the raw TIFF to the end of the file*

aaronfranke said:
It does strip that information, but I never want that information to be saved. Furry art images are not photographs with embedded location data that needs preserving, it's just an image. I only care about its visual data.

The site cares about preservation. It's one thing to strip location data as that poses a safety and security risk, but metadata can include things like the ICC color profile (which dictates how an image should be displayed for proper reproduction), licensing info, and other information that people could find useful when handling the image.

magikarp said:
Also, back to webp, it also supports lossy compression. Perhaps that could be a concern?

Less tech oriented users saving their work as webp, but with lossy compression. With PNG, the only way to lose image data is to use a program that explicitly modifies it to improve effectiveness with png encoding algorithms before actually putting it through png encoding.

That is actually one of my biggest issues with most new formats. When you're dealing with PNG and JPG, it's easy; PNG is lossless, JPG is lossy. You have to take extra steps to mix it up. But with WebP and other recent formats, they can be lossless or lossy and there's no way to tell without inspecting the image itself. Aside from various encoders defaulting to lossy (either straight-up lossy mode, or discarding potentially useful color info prior to lossless processing), and people potentially not noticing they're saving lossily, another issue is when someone gets a (lossy) webp, it gets resaved as a (lossless) webp, and no one would be the wiser. Seeing compression artifacts on a PNG is a dead giveaway, but seeing compression artifacts on a WebP wouldn't raise any eyebrows. You could maybe get a sense that something's wrong if the file size is too large given the image size and amount of artifacting, but it would be more difficult to notice and figure out for sure. Or if multiple sites offer webp downloads, it may not be so obvious which is offering lossless or lossy files.

magikarp said:
the thing about bitmaps is that they don't have transparency, so you have 24 bit pixels.

just because it's compressed, it doesn't necessitate that it was compressed effectively (ie. resaving this post as png on an app in my phone reduces it to 710KB)

Also, hashes are mainly useful for looking up if an image exists on a website already as it's MUCH faster to check against a list of strings than comparing actual images. Not a necessary thing, but still more important than metadata imo.

Yeah, but I only used bitmaps as an example uncompressed format. IrfanView was source of that 'bitmap' size. It's basically stating 3 bytes-per-pixel, times height and width to get bytes. The fact that it's even BIGGER than the uncompressed data is what was funny.

savageorange said:
ICC is part of its visual data, so..

I'm satisfied with my tests of WebP's lossless option, and that it gives 10-20% smaller files pretty consistently.

GIMP for example does default to LOSSY webp export, so I think your scenario of carelessly destroying image pixels is realistic.

I do note that some webp export software may discard RGB information in fully-transparent areas; I haven't tested whether GIMP's does this. With the official CLI tool cwebp you must explicitly request that this information is preserved, by specifying -exact in addition to the baseline -lossless option.

I... have no idea who still uses GIMP. But yeah, that's yet another issue with that program. Discarding pixels when mask shows them as invisible is technically an optimization, but that does destroy some data. I could imagine someone hiding Easter eggs or the like that way. People have used layers to hide uncensored pixels, hehe.

watsit said:
The site cares about preservation. It's one thing to strip location data as that poses a safety and security risk, but metadata can include things like the ICC color profile (which dictates how an image should be displayed for proper reproduction), licensing info, and other information that people could find useful when handling the image.

That is actually one of my biggest issues with most new formats. When you're dealing with PNG and JPG, it's easy; PNG is lossless, JPG is lossy. You have to take extra steps to mix it up. But with WebP and other recent formats, they can be lossless or lossy and there's no way to tell without inspecting the image itself. Aside from various encoders defaulting to lossy (either straight-up lossy mode, or discarding potentially useful color info prior to lossless processing), and people potentially not noticing they're saving lossily, another issue is when someone gets a (lossy) webp, it gets resaved as a (lossless) webp, and no one would be the wiser. Seeing compression artifacts on a PNG is a dead giveaway, but seeing compression artifacts on a WebP wouldn't raise any eyebrows. You could maybe get a sense that something's wrong if the file size is too large given the image size and amount of artifacting, but it would be more difficult to notice and figure out for sure. Or if multiple sites offer webp downloads, it may not be so obvious which is offering lossless or lossy files.

Yeah, a lot of metadata is intentionally added/wanted/desirable, and this is why it's best if the programs exporting the image in the first place do it right. "Do you want to include personal identifiers, and not just metadata related to the image itself? Do you want to add artist name? Date and time?" in privacy settings might make this less of a problem?

I _think_ they use magic bytes near the front of the file to tell if it's lossy, but that still requires you actually decode that header. There should be more warnings in image tools when doing the lossy round trip. This is not actually the user's fault, but a poor design decision not to make them aware of it.

kora_viridian said:
I am told that on some other image boards, it was possible, at one time, to do something like cat nasty.jpg >>puppy.jpg on your machine, and then post puppy.jpg to the image board. Anybody reading the site with a Web browser would see a cute puppy, but if they downloaded the image and cut off everything from byte 0 to the second JPEG header, they could see nasty.jpg in an image viewer.

You can still do it... Most sites will shave it off, but if they don't, it's still there.

alphamule said:
I... have no idea who still uses GIMP.

Why not?

It's still the dominant program of its type on Linux AFAICS. You either use CLI tools for image editing/conversion or GIMP. Krita is not an alternative to GIMP nor is it trying to be.

People even seem to use it on Windows despite that port being extremely under-maintained (basically 1 dev focused on that).

kora_viridian said:
I am told that on some other image boards, it was possible, at one time, to do something like cat nasty.jpg >>puppy.jpg on your machine, and then post puppy.jpg to the image board. Anybody reading the site with a Web browser would see a cute puppy, but if they downloaded the image and cut off everything from byte 0 to the second JPEG header, they could see nasty.jpg in an image viewer.

This is true. But the easier technique is to append a zip file containing the content you want. Then you can just 'unzip' puppy.jpg, it will skip the 'junk data at start' and extract nasty.jpg.

It's possible with most formats IIRC and works within any system which doesn't specifically try to scan and remove extraneous content.

savageorange said:
Why not?

It's still the dominant program of its type on Linux AFAICS. You either use CLI tools for image editing/conversion or GIMP. Krita is not an alternative to GIMP nor is it trying to be.

I use gimp fyi and that is the only other software I know to use besides microsoft paint.

alphamule said:
Yeah, but I only used bitmaps as an example uncompressed format. IrfanView was source of that 'bitmap' size. It's basically stating 3 bytes-per-pixel, times height and width to get bytes. The fact that it's even BIGGER than the uncompressed data is what was funny.

I disagree because PNG can be larger because it has high bpp formats (for increased color depth).

bmp supports a max of 32 bits per pixel.
png supports a mas of 64 bits per pixel.

I saved the image in an equivalent format (32bpp, basically just bmp with transparency), and the size was the same as the png, proving that the pbg version just has zero compression. In practice, if you have any compression enabled then it will make your image smaller than the raw equivalent.

I know you only used the "X is somehow bigger than Y" as an example but I'm pointing out that it has reasonable explanations, so using it as hyperbole glosses over the details.

Tying this back to the topic: even in the instance of this obscenely large png, there's at least no loss of visual information like there would be with jpeg. Png files are already larger than jpg but avoiding loss of information is always more important than reducing the original filesize.

Foolproofing the process as much as possible and simply recommending that artists export directly to PNG avoids any potential loss of data, and most instances should have pretty good compression too.

For the GIMP discussion above, I use GIMP for advanced image editing (but rarely for e621). Not to be confused with optimization tools like oxipng and cwebp which I use for uploading optimized files.

Can we please get WebP support? I would like the ability to upload images in this format, both for regular images and animated images.

For animated images, GIMP supports exporting animations in the GIF or WebP formats. GIF is terrible, lacking color depth, good compression, etc. Animated PNG is a pain because GIMP has no support for it so I would have to grab a third-party tool. WebP is the superior format for animated images, compared to animated PNG it has widespread support and better compression, and compared to GIF it has much better color depth.

For regular non-animated images, this has been extensively discussed above, but again WebP is the superior format with lots of advantages. Nearly everything has support for it: browsers, operating systems, image editors like Photoshop, GIMP, Krita, Procreate, Paint.NET, etc. Everything except furry art sites.

What is required for e621 to add WebP support? On a technical side, it's just adding a format to the list of allowed formats, right? Plus the ability to rescale those files for thumbnails. On the non-technical side, is the bottleneck really just "other furry art sites aren't doing it so we won't do it"? If so, I disagree with that reasoning, I don't think progress should be hindered by a chicken and egg problem. Give artists a better format and some would choose to use it. Otherwise, nobody can use it so of course the adoption rate would be 0%.

aaronfranke said:
Can we please get WebP support? I would like the ability to upload images in this format, both for regular images and animated images.

For animated images, GIMP supports exporting animations in the GIF or WebP formats. GIF is terrible, lacking color depth, good compression, etc. Animated PNG is a pain because GIMP has no support for it so I would have to grab a third-party tool. WebP is the superior format for animated images, compared to animated PNG it has widespread support and better compression, and compared to GIF it has much better color depth.

For regular non-animated images, this has been extensively discussed above, but again WebP is the superior format with lots of advantages. Nearly everything has support for it: browsers, operating systems, image editors like Photoshop, GIMP, Krita, Procreate, Paint.NET, etc. Everything except furry art sites.

What is required for e621 to add WebP support? On a technical side, it's just adding a format to the list of allowed formats, right? Plus the ability to rescale those files for thumbnails. On the non-technical side, is the bottleneck really just "other furry art sites aren't doing it so we won't do it"? If so, I disagree with that reasoning, I don't think progress should be hindered by a chicken and egg problem. Give artists a better format and some would choose to use it. Otherwise, nobody can use it so of course the adoption rate would be 0%.

Webp support is a bad idea so no from me. I don't think the admins are interested either.

What makes it a bad idea? It has lots of advantages, I don't see a reason to not allow it alongside PNG and JPG.

an example from Watsit
https://e621.net/forum_topics/22506?page=1#forum_post_372235

Plus, the website supports up to 100 mb, again there is no point posting something compressed, worst case scenario a janitor who is half-drunk thinks the file is smaller and worse quality (although its not), so they replace it with the uncompressed version. The only good reason Ive seen so far was some artists post webp instead of png or jpg, so it would be better to upload the webp over converting them to another format.

"Should we allow recompressing as webp" and "Should we support webp" are different questions. IMO the answer to the former is obviously no, but the latter is less clear.

(you actually linked to my post, I think you wanted a post that was about 4 down from it talking about the difficulty of telling whether a given file is genuinely rather than nominally lossily or losslessly compressed, because this could be silently changed on resaving.)

savageorange said:
"Should we allow recompressing as webp" and "Should we support webp" are different questions. IMO the answer to the former is obviously no, but the latter is less clear.

(you actually linked to my post, I think you wanted a post that was about 4 down from it talking about the difficulty of telling whether a given file is genuinely rather than nominally lossily or losslessly compressed, because this could be silently changed on resaving.)

Right. The issue I brought up was with people carelessly using it and not realizing when they're (re)saving lossily and making an image messier than desired, and so its use for artwork should be discouraged. But if an image exists that is already webp, and the only source is webp, we should be able to archive it as-is. The alternative is to recompress as png, which when a webp can be lossy, converting a lossy image to png is generally frowned upon (as it increases the filesize, and gives the false impression that the image is a lossless png despite having lossy artifacts from the original webp).

The true original file is almost always a project file, something like a .psd, .kra, .xcf, or .clip file. When it's exported from the art program, it needs to be converted to a regular image format like PNG or WebP. So it's already converted.

I always intend to post perfectly preserved lossless images where possible, and WebP allows us to have lossless images with less file size. Sure, some people could save it lossily, but people can already make that mistake with JPG. I don't see how allowing using a better image format is a bad thing for people who know what they're doing.

wolfmanfur said:
Plus, the website supports up to 100 mb, again there is no point posting something compressed

Alright, then should we all switch to BMP files, right? Because there is no point to compression?

It's not about fitting within the maximum size the site supports. If e621 allowed images up to 1 TB, that still doesn't mean it would be a good idea to purposefully post an uncompressed image.

If we can get the same exact image but with less file size, that saves storage costs, download time, and bandwidth. Or, we can have increased quality in the same file size as before. Lossless compression is great.

aaronfranke said:
The true original file is almost always a project file, something like a .psd, .kra, .xcf, or .clip file. When it's exported from the art program, it needs to be converted to a regular image format like PNG or WebP. So it's already converted.

Your point? I did say it was better to post the artist's wenp file over converting it to png, agreeing with you on that front.

I always intend to post perfectly preserved lossless images where possible, and WebP allows us to have lossless images with less file size. Sure, some people could save it lossily, but people can already make that mistake with JPG. I don't see how allowing using a better image format is a bad thing for people who know what they're doing.

Not everybody is as dilligent as you are.

Jpeg is never a good format to upload, it gets replaced by a png every so often, it is only allowed as a file here because it is popular and anyway converting it to png won't remove the jpeg artifacts.

Alright, then should we all switch to BMP files, right? Because there is no point to compression?

Not only is it not widely supported by webserver frameworks, but as a result it is very rare. There is no option for bmp for the same reason tiff is not allowed and ico is not supported either.

Oh, and yes we should all switch to png, I like my pixels crisp. Artists who post jpegs are war criminals.

It's not about fitting within the maximum size the site supports. If e621 allowed images up to 1 TB, that still doesn't mean it would be a good idea to purposefully post an uncompressed image.

I think everybody understood that, but is it a reason to do it? There is still that problem Watsit mentioned above where people will post lossy webp instead of lossless. What would you do to remedy this?

If we can get the same exact image but with less file size, that saves storage costs, download time, and bandwidth. Or, we can have increased quality in the same file size as before. Lossless compression is great.

We got it, but there are multiple caveats and no matter how often you repeat this, they will always be there.

wolfmanfur said:
There is still that problem Watsit mentioned above where people will post lossy webp instead of lossless. What would you do to remedy this?

I would do nothing specific. I think it's clear enough when you export WebP from an art program and you get to select the quality level. It doesn't make sense to me to prevent artists from using any options they want when exporting from their art program.

However, if you are really concerned about this, another option is we could make it so that e621 will only accept lossless WebP and not lossy. But I disagree with this, because lossy WebP is also a good format worth supporting. Do keep in mind that the artifacts in lossy WebP are vastly less of a problem than JPEG. Artifacts in JPEG are horrendously ugly color splotches, while artifacts in lossy WebP just result in the image being a bit blurry, it's much harder to notice for the same quality setting. Lossy WebP is much crispier than JPEG. To be clear I also prefer lossless, but, lossy WebP is pretty good.

I have encountered a new problem. An artist sent me a PNG file which is 6090x3540 resolution. The image is extremely detailed and even after running it through oxipng, the file size is still 82850819 bytes. If I open it in GIMP and save it as PNG again then the file is 85674648 bytes. This is above e621's 75 MB limit. https://e621.net/help/supported_filetypes However, if I open the image in GIMP and save it as a lossless WebP, the file size is only 9719946 bytes.

So with the current state of e621, it's literally impossible for me to upload this file losslessly, but if e621 supported WebP then it would be possible for me to upload, and it would be less than 1/8th the file size. Without WebP support, I will be forced to convert this PNG to a JPEG (a 90% quality JPEG is 2738386 bytes, 3.3% of the optimized PNG size).

aaronfranke said:
I have encountered a new problem. An artist sent me a PNG file which is 6090x3540 resolution. The image is extremely detailed and even after running it through oxipng, the file size is still 82850819 bytes. If I open it in GIMP and save it as PNG again then the file is 85674648 bytes. This is above e621's 75 MB limit. https://e621.net/help/supported_filetypes However, if I open the image in GIMP and save it as a lossless WebP, the file size is only 9719946 bytes.

So with the current state of e621, it's literally impossible for me to upload this file losslessly, but if e621 supported WebP then it would be possible for me to upload, and it would be less than 1/8th the file size. Without WebP support, I will be forced to convert this PNG to a JPEG (a 90% quality JPEG is 2738386 bytes, 3.3% of the optimized PNG size).

Send me the image I think I can do something about it.

aaronfranke said:
I have encountered a new problem. An artist sent me a PNG file which is 6090x3540 resolution. The image is extremely detailed and even after running it through oxipng, the file size is still 82850819 bytes. If I open it in GIMP and save it as PNG again then the file is 85674648 bytes. This is above e621's 75 MB limit. https://e621.net/help/supported_filetypes However, if I open the image in GIMP and save it as a lossless WebP, the file size is only 9719946 bytes.

So with the current state of e621, it's literally impossible for me to upload this file losslessly, but if e621 supported WebP then it would be possible for me to upload, and it would be less than 1/8th the file size. Without WebP support, I will be forced to convert this PNG to a JPEG (a 90% quality JPEG is 2738386 bytes, 3.3% of the optimized PNG size).

When you saved it in GIMP, seeing as we're talking about quality with JPGs anyway, what compression did you use? I find it hard to believe even setting it as low as, say, 2 wouldn't manage to get even that large of an image under 75mb, especially if you removed metadata, colour profile, etc. etc..

Here is the unusually big image https://drive.google.com/file/d/1sMy9_nGXFYV_3ASk59ORHZWBou_DV5Xg/view?usp=sharing

votp said:
When you saved it in GIMP, seeing as we're talking about quality with JPGs anyway, what compression did you use? I find it hard to believe even setting it as low as, say, 2 wouldn't manage to get even that large of an image under 75mb, especially if you removed metadata, colour profile, etc. etc..

I used compression level 9.

aaronfranke said:
Here is the unusually big image https://drive.google.com/file/d/1sMy9_nGXFYV_3ASk59ORHZWBou_DV5Xg/view?usp=sharing

I used compression level 9.

There's no reason for that image to be that big.

Compression level 9 and RGB 8bpc reduces it to 13 449 232 bytes

Well I don't know what's going on with this image, but if e621 supported WebP, I could just upload that and would be even less bytes anyway.

reports the source png as 16bits per channel RGBA. Alpha stats are

min: 64321  (0.981476)
       max: 65535 (1)
       mean: 65518.5 (0.999749)
       median: 65535 (1)
       standard deviation: 101.745 (0.00155253)
       kurtosis: 67.5891
       skewness: -6.84936
       entropy: 0.0713187

(ie. no meaningful transparency, all pixels are at least 98% opaque), so the alpha channel should never have been exported to begin with. For a web upload, it should probably have been exported at 8bpc RGB by the original artist.

My guess is that the webp export just dropped the extra precision (I've seen claims it supports up to 10 bits per channel, but the technical info I can find suggests 8 bits per channel). I think e6 would count that as image degradation.

savageorange said:
identify -verbose corbin\ and\ panda.png reports the source png as 16bits per channel RGBA. Alpha stats are

min: 64321  (0.981476)
       max: 65535 (1)
       mean: 65518.5 (0.999749)
       median: 65535 (1)
       standard deviation: 101.745 (0.00155253)
       kurtosis: 67.5891
       skewness: -6.84936
       entropy: 0.0713187

(ie. no meaningful transparency, all pixels are at least 98% opaque), so the alpha channel should never have been exported to begin with. For a web upload, it should probably have been exported at 8bpc RGB by the original artist.

My guess is that the webp export just dropped the extra precision (I've seen claims it supports up to 10 bits per channel, but the technical info I can find suggests 8 bits per channel). I think e6 would count that as image degradation.

I'll look into it, too. I wonder how many unique colors, etc. this has. There might be other ways around this.

Hmm, 1181192 unique colors, so about 20.1718 bits of precision per pixel.
log_2(1181192)*6090*3540 / 8 -> you need 54,359,504 bytes to store this raster image uncompressed with a 'perfect' palette representation (not counting the size of said palette).
The palette is 1181192*64/8 = 9,449,536 bytes. Total size would be 63,809,040 bytes not counting headers. So this image 'should' be able to be brought down below 64MB.

For laughs, tossed it at OptiPNG with maximum CPU time. I'll post results in an hour or 2 (half joking). Ouch, was reading specs and apparently, PNG does not support palettes larger than 8-bits-per-pixel (256 unique colors)? Damn, that wrecks my math.

So, I output a PNG file that is 12.7MB, but it reduced it to 24-bit color (but the number of colors is the same). Bah, oh well. This is as good as it's going to get without using a different tool or even format. That is a nice reduction, though. Interestingly, all of the PNG files that I've uploaded are 24-bit, anyways, so this limitation would not have matter for me. I agree that for higher-BPP, or when using other color spaces, PNG is not very optimal or even compatible.

It sucks, but an alternative is to provide source links with the full resolution in description and source list? :( Save them on the Wayback machine, if you do. The entire point is preservation.

Note: That link expires in 3 days, used in case you don't want it to stick around.

Tried the OptiPNG program directly in command line with most aggressive options and it repeats "IDAT too big" over and over, haha. It makes no sense that I can get an 8-bit-per-channel image to 12.7MB, but can't get a 16-BPC image to less than 75MB (it shouldn't be more than about twice the 24-bit image). Now we know why. You'll have to find something that can handle that huge-ass IDAT chunk.

savageorange said:
(ie. no meaningful transparency, all pixels are at least 98% opaque), so the alpha channel should never have been exported to begin with. For a web upload, it should probably have been exported at 8bpc RGB by the original artist.

I mean, I coulda told ya that, given that's what I just did to the thing. A lot of "big" images are only that big due to folks not actually learning what export setting are. Can't fault them, really, some of it's confusing.

https://css-ig.net/benchmark/png-lossless
Most people are interested in run times and compression rate. The test set they use has hilariously small files by today's standards.

https://www.mobileread.com/forums/showthread.php?t=354678 http://web.archive.org/web/20230815124516/https://medium.com/@duhroach/reducing-png-file-size-8473480d0476 I'm trying to find one that works well with this specific file/requirements. OptiPNG works for outputting 48-bit color when used directly (instead of with IrfanView) but doesn't seem to like that big monster of a file. Of course, if you want to do lossy options, you can get better results but that isn't exactly going to go over very well on an archive site. XD It's still an option if running a site and you want fast-to-compress, small-size previews that won't bog down your mobile users. JPEG is the other popular choice but meh.

After running this line for hours: optipng -o7 -v -zc9 -zm9 -zs3 -keep "corbin and panda.png" -out "corbin and panda_recompressed64bpp_d.png"

That's about as good as possible with OptiPNG and original colors.
https://litter.catbox.moe/773lox.png 10MB shy of the goal. Oh well.

VoTP said:
big

"big" is just a word which certainly will not invoke the right implications in the mind of someone who is not even aware that high bit depth images are a thing
(most people on the web, IMO).

alphamule said:
I agree that for higher-BPP, or when using other color spaces, PNG is not very optimal or even compatible.

??? It's not as good as, say, EXR, but it's one of the few "mainstream" formats that has sensible high-bit-depth support. Of course as you noted, not all optimizers will handle high bit depth well (I imagine most of them just expect 'you exported 24/32bpp RGB/A because you are trying to display this image on the web.').

>8bpp palette support has always been super niche. A palette with >8bits per channel of precision is even more niche. (and for the average image that actually makes good use of high bit depth, palettization would not be a good optimization strategy anyway.).

savageorange said:
>8bpp palette support has always been super niche. A palette with >8bits per channel of precision is even more niche. (and for the average image that actually makes good use of high bit depth, palettization would not be a good optimization strategy anyway.).

GIF? :P

Well, by higher bit depths... I was also including 10-bit-per-channel. But yeah, 64-bit if you can find a tool that creates it in the first place. For the longest time, you couldn't even display better than 8-bit-per-channel.

It's funny how they wanted to re-compress the image into a jpeg with 90% quality while all it took to compress the image was to remove the Alpha channel and change png compression settings. This hyperfocused obsession with webp is starting to become un healthy aaronfrank.

Talking of lossy compression, forcing a 255 indexed color palette (like gif) would have reduced the file size by at least 50% and the image would still look as good as it did before, simply by the fact that there ain't no artifact vomit on the image. It's possible on gimp too!

It bears repeating, but there is never a day where using jpeg is justified and the day where webp will be needed because a png image is too big and impossible to compress. Something nasty like 100000x100000, and it uses as many colors as possible and so it is 200mb. Only that day will that discussion be wort having.

wolfmanfur said:
... Something nasty like 100000x100000, and it uses as many colors as possible and so it is 200mb. Only that day will that discussion be wort having.

I swear I've seen an image close to that resolution on here, can't remember what format it was, probably .jpg.

wolfmanfur said:
It's funny how they wanted to re-compress the image into a jpeg with 90% quality while all it took to compress the image was to remove the Alpha channel and change png compression settings.

Bits per channel is not a compression setting, it's modifying the actual image pixels, ie. yes, it IS lossy. Nobody has posted results for a non-lossy export that comes under the limit.
Just dropping the alpha channel without dropping the bpc might work well enough though.

Most people won't be able to tell the difference between 8 and 16 bpc but that's not really an excuse, for an archiving website.

Something nasty like 100000x100000, and it uses as many colors as possible and so it is 200mb.

Nah. Webp actually is limited to 16383x16383 pixels, because width/height are encoded in 14bit fields.
JPEG-XL would be a better choice in that case, it handles w/h up to ~1 gigapixel per side ((2^30)-1).

FWIW by comparison jpeg max is 65535x65535 pixels and png max is ~2 gigapixels per side ((2^31)-1). (I only suggest JPEG-XL over PNG because my tests lead me to think that for very large images it's gonna crush PNG's compression)

There will never be a human need for an image format with more than 8 bits per channel, a video format with more than 60 frames per second, or an audio format with more than 256 kilobits per second.

wat8548 said:
There will never be a human need for an image format with more than 8 bits per channel, a video format with more than 60 frames per second, or an audio format with more than 256 kilobits per second.

Is this a reference to the '640k is plenty' bill gates quote?
Because literally all of those claims are wrong.

wolfmanfur said:
It's funny how they wanted to re-compress the image into a jpeg with 90% quality while all it took to compress the image was to remove the Alpha channel and change png compression settings. This hyperfocused obsession with webp is starting to become un healthy aaronfrank.

Why should I have to mess with PNG compression settings and wait hours for oxipng/optipng to run when I could just use WebP and it will give me a better image in seconds that is compatible will all modern devices and all modern web browsers?

e621's resistance to WebP is unhealthy :)

wolfmanfur said:
Talking of lossy compression, forcing a 255 indexed color palette (like gif) would have reduced the file size by at least 50% and the image would still look as good as it did before, simply by the fact that there ain't no artifact vomit on the image. It's possible on gimp too!

No, that's horrible. Quantizing the image down to a smaller color palette makes the image look way worse than using JPEG.

Look at this: https://i.imgur.com/zQ0wYcL.png

The quantized reduced palette version looks bad and is larger than the JPEG. You probably are finding it hard to tell which one is the JPEG, so here are the labels: https://i.imgur.com/Y8RxEGh.png

Anyone who thinks that reducing the color palette is an acceptable solution is just wrong. If you just do the test as I did, it's painfully obvious.

Also, anyone who thinks GIF is a good format is also plain wrong and has no idea what they're talking about, it's orders of magnitude worse than animated WebP, animated PNG, and video formats like WebM, MP4, etc.

I'll take gifs over WebPs any day, especially given the recent buffer overflow issue . You basically have two options when it comes to making an image fit within an upload limit; reduce the data in the image itself (scrubbing metadata, removing unused transparency, reduced palette, other compression or optimisations as-format-appropriate) or simply scaling it down to a more reasonable size.

All you've really done is make an argument in favour of JPEG over WebP to me from what you've shown. Mozjpeg time?