Open Krabbyos opened 4 years ago
BrokenEagle
commented
4 years ago I don't see any issue with the above. The dimensions reported by URL 0 are for the /original/ image, which is no longer available. Therefore, /4k/ is always the largest size.
If there's nothing else, you can go ahead and close the issue. I'll close it if I don't hear anything else by tomorrow.
lllusion3469
commented
4 years ago For the example they mentioned, /large/ (which is available) is bigger than /4k/ (but still smaller than the original) but the strategy picks the smaller - /4k/.
If the limits in OP are correct, you could go by the aspect ratio to choose the bigger one.
BrokenEagle
commented
4 years ago Oh I see, I read the OP wrong.
Still, this will be a difficult fix, since AFAIK the largest image is always chosen based upon the image scheme (and not comparing images after they are downloaded). IIRC there is a mechanism to choose the next image size if one of the images in the size list 404s, but that doesn't help out with this.
However, forcing the system to have to download multiple images every time to make a comparison would be pretty resource intensive. I'm not sure that's the best way to go.
It would instead be optimal if there is some way to determine the largest image size without having to download anything. Maybe using a combination of the original image dimensions and the 4k limits could be used? If someone could research that and determine if there was a pattern, that would help determine which direction the fix needs to go.
lllusion3469
commented
4 years ago Well, if these limits always hold:
/large/resolution limits
- 1920 width
- no limit height (though see note at bottom here on upload limits: https://help.artstation.com/en/articles/40-how-do-i-get-the-best-quality-of-images-on-artstation)
/4k/resolution limits
- 3840 width
- 3840 height
Then /large/ should be bigger if
original_height > 3840 (they aren't going to upscale it)
original_height * 1920 / original_width > 3840 (original_height * 1920 > original_width * 3840)
original_height / original_width > 2 (original_height > 2 * original_width)In this case the downscaled height is 3955.2 using the formula and 3955 in /large/
E: I meant /large/, not /4k/
Krabbyos
commented
4 years ago After correcting my errors, it seems that lllusion3469 and my analysis agrees
resizing cases based on original resolution (original res can be viewed in the .json links) resizing keeps aspect ratio resizing is always downscaling, so no-resize versions are always larger
w = original width
h = original height
if
w <= 1920, h <= 3840
/large/: no resize
/4k/: no resize
get /4k/ (both are same resolution. just default to something)
w <= 1920, h > 3840
/large/: no resize; ie (w x h)
/4k/: resize to (3840*(w/h) x 3840)
get /large/
1920 < w <= 3840, h <= 3840
/large/: resize to (1920 x 1920*(h/w))
/4k/: no resize
get /4k/
1920 < w <= 3840, h > 3840
/large/: resize to (1920 x 1920*(h/w))
/4k/: resize to (3840*(w/h) x 3840)
if h/w > 2
get /large/
else
get /4k/
w > 3840, h <= 3840
/large/: resize to (1920 x 1920*(h/w))
/4k/: resize to (3840 x 3840*(h/w))
get /4k/
w > 3840, h > 3840
/large/: resize to (1920 x 1920*(h/w))
/4k/:
if w > h
resize to (3840 x 3840*(h/w))
get /4k/
else w <= h
resize to (3840*(w/h) x 3840)
if h/w > 2
get /large/
else
get /4k/
mdashlw
commented
1 month ago I noticed https://cdna.artstation.com/p/assets/images/images/023/424/128/4k/star-academy-aisha1.jpg in the example now returns 2500x5150, so /4k/ is possibly the best version now regardless.
url where this behavior shows up:
from url 0, image is originally (2500 x 5150) image from url 2 (/large/) is (1920 x 3955) but image from url 3 (/4k/) is (1864 x 3840)
ok so artstation resolution limits are kinda wonky. As far as i can tell,
/large/ resolution limits
/4k/ resolution limits