Donmai

Image Replacement Request Thread

Posted under General

This topic has been locked.

D1ce said:

post #2863940

I used the bookmarklet, and apparently it uploaded the "large" format Artstation image and not the "original"?

? Looks fine. Although, hrm.... I don't really get ArtStation, because I keep retrieving a lossy webp (Google's own lossy/lossless image format)... Someone might be able to figure this out better than I can.

I'll let BE98 know when I see him later although I think he'll see it.

post #2680931
https://i.pximg.net/img-original/img/2016/12/14/20/25/58/60376022_p0.jpg

It's not a sample, but it's cropped and no source. I presume the intention was to remove the letterbox, but it's cropped a few pixels past that and it's deceptive/wasteful being a png because the original export was lossy. For some reason I'm in a friendly mood, because I really should have just uploaded the right one myself and flagged the sourceless one. But I did manage to create a crop of the pixiv image that is identical to the one uploaded here, so it's definitely from that.

Fun fact: ImageMagick can actually screw up colors converting from jpg to png in some case. I'm not yet sure what makes that case happen, but that's literally the last piece of software I'd have expected to get that wrong. You learn something new every day.
(Edit: Exactly as kittey says. convert -define jpeg:dct-method=islow 60376022_p0.jpg -crop 1920x976+0+57 +repage produces an image identical to what used to be uploaded here.)

Updated

☆♪ said:

post #2680931
https://i.pximg.net/img-original/img/2016/12/14/20/25/58/60376022_p0.jpg

It's not a sample, but it's cropped and no source. I presume the intention was to remove the letterbox, but it's cropped a few pixels past that and it's deceptive/wasteful being a png because the original export was lossy. For some reason I'm in a friendly mood, because I really should have just uploaded the right one myself and flagged the sourceless one. But I did manage to create a crop of the pixiv image that is identical to the one uploaded here, so it's definitely from that.

Fun fact: ImageMagick can actually screw up colors converting from jpg to png in some case. I'm not yet sure what makes that case happen, but that's literally the last piece of software I'd have expected to get that wrong. You learn something new every day.

Thanks for your hard work. You're a good person :)

☆♪ said:

Fun fact: ImageMagick can actually screw up colors converting from jpg to png in some case. I'm not yet sure what makes that case happen, but that's literally the last piece of software I'd have expected to get that wrong. You learn something new every day.

Most applications use (slow) integer DCT to de-/encode JPEGs but ImageMagick uses float DCT by default, which results in slightly different colors.

If that’s a problem for you, use this option on whatever ImageMagick program you’re using: -define jpeg:dct-method=islow
IIRC, that option must go before the file you want to apply it to.

kittey said:

Most applications use (slow) integer DCT to de-/encode JPEGs but ImageMagick uses float DCT by default, which results in slightly different colors.

If that’s a problem for you, use this option on whatever ImageMagick program you’re using: -define jpeg:dct-method=islow
IIRC, that option must go before the file you want to apply it to.

Phew, color precision... sounds like too much for me to think about, orz.

Just as ☆♪ says, you do learn something new everyday.

Anyways, sorry, I just remembered to replace it now. Thanks for telling me.

kittey said:

Most applications use (slow) integer DCT to de-/encode JPEGs but ImageMagick uses float DCT by default, which results in slightly different colors.

Does that include browsers like Firefox and Chrome? If so, that explains why it takes a while to load up very large images.

tapnek said:

Does that include browsers like Firefox and Chrome? If so, that explains why it takes a while to load up very large images.

Desktop Firefox uses (slow) integer DCT (usually just called “integer”). I don’t use Chrome, so I can’t say anything about it. Ask your search engine of least distrust if you’re interested. I can imagine that mobile browsers use the less precise fast integer DCT to conserve battery power, though.

Simple benchmark, decoding a 3500 x 5000 px JPEG with ImageMagick
fast integer0.7 s
integer0.75 s
float0.8 s

 
“Fast” integer DCT isn’t much faster than normal integer DCT, but it’s a lot less precise, which is why almost nobody uses it.
The speed of the float DCT depends on the system’s FPU. While it’s slightly more precise than the integer method, it has the big disadvantage that it completely depends on the FPU and doesn’t produce the same result on every system.

I don’t think the DCT algorithm actually has that much influence on the load time. When displaying (large) images in a browser, most of the time is probably used for copying all that image data around through the various stages and security separations and then rendering it.

This is getting a bit off-topic. Feel free to dm me if there are further questions.

Actually, no. It alternates between two files. Not sure why, maybe browser related.

https://danbooru.donmai.us/data/__kashima_and_katori_kantai_collection_drawn_by_gengetsu_chihiro__a62c2665c96154a783900db0860bd862.jpg

&

https://danbooru.donmai.us/data/a62c2665c96154a783900db0860bd862.jpg

The second one is the broken file. Well at least that explains why it was still problematic after replacing 3 times. Not sure why it's loading that old file though.

Well, it shouldn't need any more replacements.

1 2 3 4 5 6 7 8 9 35