Posted under General
john1980 said:
- Although, it seems like changing from a hard limit to a XX% limit would be even easier. Wouldn't that just be changing a few lines of code? Like
image.width > Limits.width * (1+Limits.percent_leeway)
instead of
image.width > Limits.width
I can do this but what would be a good percentage? 50%? 100%?
albert said:
john1980 said:
- Although, it seems like changing from a hard limit to a XX% limit would be even easier. Wouldn't that just be changing a few lines of code? Like
image.width > Limits.width * (1+Limits.percent_leeway)
instead of
image.width > Limits.widthI can do this but what would be a good percentage? 50%? 100%?
50% would be fine.
Is there no chance for an option to this? I just looked and you changed the top message and now it's harder to save images, seeing as the original image link leads to a danbooru page rather than an image.
albert said:
New behavior: if an image is larger than 2100x1500 pixels, it'll get scaled down to 1400x1000.
Sounds good!
Perhaps the test should be done on area, however, instead of on each dimension separately. For example, post #211358 is a mere 545400 pixels (vs a limit of 3150000), yet it got scaled down because it's very tall and thin.
Awesome that the threshold-with-leeway got implemented!
However, I think that the leeway percentage works best when a lower value is used. With the current 50%, there is an entire 700 horizontal & 500 vertical pixel (around 1/2 of typical screen resolutions!) gap between what triggers a resize and what images are resized down to. Since the leeway is merely supposed to prevent the "original image" from being larger by a small, imperceptible amount, I'd suggest a percentage more around 15-20%.
Also, in the "original image" link (perhaps underneath, making the link a rather noticeable two lines of bold ;p), would it be possible to display the resolution of the image? I could be wrong, but I imagine that is what people are looking for more than the file size when deciding whether to view an image in all its high res glory.
And it's always encouraging to see that the folks administering Danbooru take time to listen to the community's feedback. Thanks, guys!
LaC:
The *entire purpose* of this resizing is to make images fit within the bounds of the screen. To do so, you have to evaluate each dimension separately. Evaluate by area, and images are no longer guaranteed to fit in the same bounding box.
Updated
StarlitVoyager said:
However, I think that the leeway percentage works best when a lower value is used. With the current 50%, there is an entire 700 horizontal & 500 vertical pixel (around 1/2 of typical screen resolutions!) gap between what triggers a resize and what images are resized down to.
FWIW, my original suggestion (in ticket #185, which should probably be updated now) was 25%, but I think 50% is fine.
Since the leeway is merely supposed to prevent the "original image" from being larger by a small, imperceptible amount
Not as far as I'm concerned. See my previous posts.
Also, in the "original image" link (perhaps underneath, making the link a rather noticeable two lines of bold ;p), would it be possible to display the resolution of the image? I could be wrong, but I imagine that is what people are looking for more than the file size when deciding whether to view an image in all its high res glory.
It's on the left under Statistics.
LaC:
The *entire purpose* of this resizing is to make images fit within the bounds of the screen. To do so, you have to evaluate each dimension separately. Evaluate by area, and images are no longer guaranteed to fit in the same bounding box.
Not at all. That is the purpose of the client-size resizing (enable it in your settings if you haven't), which has been available for a long time and isn't going anywhere. The server-size resizing serves a completely different purpose: namely, to prevent horribly slow page loads when viewing a very high resolution post.
LaC said:
Not at all. That is the purpose of the client-size resizing (enable it in your settings if you haven't), which has been available for a long time and isn't going anywhere. The server-size resizing serves a completely different purpose: namely, to prevent horribly slow page loads when viewing a very high resolution post.
Sorry, but he's right: a primary purpose (not the only one) of this feature is to make images fit in the browser window. Browser resizing sucks: resize a large image using with your browser's filtering and it looks like crap. Supposedly FF3 improves this, but until TabMixPlus works in it, I can't even give it a test run. If it has, then it's okay by me to resize to a bit larger than the browser window--pick a resolution a bit higher than any browser window but within reasonable limits, so it's sane to load, and let browser resizing do the rest.
The other primary purpose is to avoid loading enormous images in browser in the first place, since it causes Firefox to crawl to a halt and use massive amounts of memory. I had to restart constantly when browsing moe before.
LaC said:
Not at all. That is the purpose of the client-size resizing (enable it in your settings if you haven't), which has been available for a long time and isn't going anywhere. The server-size resizing serves a completely different purpose: namely, to prevent horribly slow page loads when viewing a very high resolution post.
But someone involved in implementing it has this to say:
petopeto said:
That was just a nice bonus; the major impetus was making high-res images less painful to view in-browser.
Also, the client-side resizing is of rather blocky quality compared to the high-quality resampling of these new "sample" images.
LaC said:
FWIW, my original suggestion (in ticket #185, which should probably be updated now) was 25%, but I think 50% is fine.Not as far as I'm concerned. See my previous posts.
And I really don't understand the purpose of giving a leeway besides not resizing images that are just a bit over the limit. Nor can I find anything in your previous posts that addresses this. Having a huge leeway seems to be a bizarre way of sort-of increasing the limit. After all, you're going to allow images 2100 wide, but then resample one 2110 wide all the way down to 1400? How is this any less ridiculous than resizing an image merely 1 pixel over a hard limit? It just takes it to the opposite extreme. In my opinion, it seems best to keep the maximum image size at least *somewhat* close to the resized size. Otherwise, it would appear that the system is indeed coded to penalize images that are too large.
LaC said:
It's on the left under Statistics.
Ah, thank you. I've never really much paid attention to the Statistics values. And I have to say, after checking out moe.imouto.org I love how clearly they have the image resizing implemented there.
Updated
petopeto said:
Sorry, but he's right: a primary purpose (not the only one)
So he's wrong, since he said it was "the *entire purpose*". I guess I was only partially right, though.
Browser resizing sucks: resize a large image using with your browser's filtering and it looks like crap.
No, not with my browser.
Supposedly FF3 improves this, but until TabMixPlus works in it, I can't even give it a test run.
The current dev build (http://tmp.garyr.net/tab_mix_plus-dev-build.xpi) seems to work with FF3b4.
StarlitVoyager said:
But someone involved in implementing it has this to say:
Also, the client-side resizing is of rather blocky quality compared to the high-quality resampling of these new "sample" images.
Why does everybody assume that there is only one web browser? Safari's client-side scaling, for one, looks better than the samples.
Updated
There is a problem with the current implementation. Example:
http://i.imgur.com/lCqa0.png
post #889298
stated percentage: 27%
image: 3183 x 2448 = 7791984 pixels
sample: 850 x 653 = 555050 pixels
actual percentage: 7.12%
Either the calculation should be changed, or the text ("This image is displayed at x% of its original width").
Image A has n*m pixels. An image B is "twice as big" as image A if it has 2n*2m pixels = if the width and height are doubled. It's size is 200% of A's size.
This means that when image A has n*m pixels, image B is "50% of image A's size" if it has (n/2)*(m/2) pixels.
An image at 50% size has 25% of the area of the full (100%) image. and an image at 27% size has 7.12% of the area of the full (100%) image.
This is the same everywhere, not just on danbooru.
Updated
