I used the bookmarklet on the Artstation post page, and apparently it uploaded the "large" format image and not the "original"?
Updated
Posted under General
This topic has been locked.
I used the bookmarklet on the Artstation post page, and apparently it uploaded the "large" format image and not the "original"?
Updated
D1ce said:
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.jpgIt'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.
| fast integer | 0.7 s |
| integer | 0.75 s |
| float | 0.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.
post #2875245
https://katsuraiyoshiaki.files.wordpress.com/2016/02/160209e69a87e4babae9ad94e78e8be38396e38383e382afe382abe38390e383bce980b2e8a18c4.jpg
Non-direct: https://katsuraiyoshiaki.com/2016/02/22/229%e3%83%a9%e3%83%8e%e3%83%99%e7%99%ba%e5%a3%b2%ef%bc%81%e6%9a%87%e4%ba%ba%e9%ad%94%e7%8e%8b%ef%bc%91%e5%b7%bb/
worldendDominator said:
post #2881227
Replace with https://i.pximg.net/img-original/img/2017/10/07/19/43/49/65322018_p0.png
We don't replace revisions... which means, upload it separately if you want it there.
replace with an re-upload from the same source. The current file on the danbooru servers is truncated and does not match.
DeltaRayEdge said:
replace with an re-upload from the same source. The current file on the danbooru servers is truncated and does not match.
Well, it looked fine to me but I attempted a replacement anyway. Do tell if it fixes your problem.
Actually, no. It alternates between two files. Not sure why, maybe browser related.
&
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.
archaist said:
post #2902479
http://konohanatei.sakura.ne.jp/images/kabegami03/2048%81~1536_iPad%20mini.jpg
The current image is higher resolution, has text, and is cropped differently. Replacements shouldn't be used for images that different. Upload it as the parent image instead.
