No.8208
I'd be more accepting of webp if it worked with GIMP or photoshop or any editing software.
No.8210
That looks lossy. Do you notice any extra ringing at edges?
No.8212
>>8211Everything is already changed and you haven't noticed.
No.8213
oh, do you mean original image compression?
No, not as yet anyways.
No.8214
Mind you, .webp has a lossless setting and a lossy setting. Both superior to .png so if I did that, aside from disregarding every old apple product from viewing the site, it would be improved.
No.8215
But anyways, no plan to alter original images aside from exif stripping on .jpg.
But that does mean that in a hypothetical future of limited disk space, filesizes of uploads could end up being minimized.
Out of many possible resolutions to this issue, it's up to what's perceived to be the lesser evil at that point.
No.8218
What site is that?
I use tinypng.com, which works really well at compressing PNGs. I don't know how else to compress it since photoshop has big filesizes. There's a paid photoshop plugin but it's not something I'd pay for
No.8219
>>8218https://ezgif.com/35MB limit
If you have the effort to learn and just want to optimize then you can probably use ImageMagick instead
No.8220
>>8210It is lossy. The WebP definitely looks softer, but it's a fool's errand to compare an already lossy image to a lossy image of the original which is also a lossy image. A fair comparison would only be if there was an original lossless image and lossy versions made using both JPG and WebP or whatever is trying to be compared.
No.8221
>>8220The artist uploaded it in jpg
https://www.pixiv.net/en/artworks/83061315probably because a 120MB image is a bit excessive.
No.8222
>>8221I said nothing to the contrary.
No.8223
>>8222well if the artist thought that a JPG was the right file format for their art, then it's not fair to discard a scenario because it doesn't suit you. Compression can be done before you notice any differences. Saying anything else is falling into the typical case of people attempting to differentiate between MP3 and WAV.
No.8224
>>8223Huh? All I said was that it's not valid to evaluate the compression of a lossy format against a lossy format if the source image is also lossy...
If the source image was a lossless image, it would be a fair comparison. Pointing out that there was image degradation between the JPG and WebP is moot because there is nothing to compare the JPG to, especially since it is the source image.
It'd be like saying it's valid to evaluate an OPUS file's compression from re-encoding a 128kbps MP3. Re-encoding artifacts are very much a real thing, so it's impossible to accurately assess the strengths of WebP in this circumstance.
No.8225
>>8224And I'm saying that for all intents and purposes, the original is a lossless image
No.8226
Or I suppose put slightly differently, it's not fair to point out the artifacting in the WebP because we have no reference to say whether the artifacting that would be present in a JPG is any less severe, or perhaps worse.
No.8227
I was asking if there were any noticeable artifacts in the optimized JPEG which I don't see posted in the thread. I wouldn't be able to tell from the screenshot because it's scaled down.
No.8230
If you look at the clock, the webp version has the best static
No.8231
actually kind of strange. The .webp attempts to clean the artifacting of .jpg
The original is actually the worst looking... but there are some flaws with each
No.8232
>>8229Thanks.
The biggest difference I've noticed so far is some subtle dithering-like speckles on the wall in the background which show up in the original but not in either recompressed version.