[X] My Assistant

It's not that easy, I'd need to set up a separate server with a non-LTS software stack to support versions of ImageMagick that are recent enough to handle animated WebPs natively.

It seems this isn’t an easy task, and it’s worth considering whether it’s necessary to do so. However, for me personally, the current approach of not resampling animated WebP files is acceptable.

Considering animated WebP won't be resampled, will its file size limit differ from static ones?
And will lossy and lossless WebP have different size limits, since lossless ones can save more % of size when resampled to lossy?

Considering animated WebP won't be resampled, will its file size limit differ from static ones?
And will lossy and lossless WebP have different size limits, since lossless ones can save more % of size when resampled to lossy?

The WebP limit is 20 MiB, like JPEG.

When attempting to search for specific keywords on the "Watched" page, a 403 error occurs.
Perhaps there is a separate restriction on the Watched page. I hope it can alert users in the same way as the main page search.

For example:
https://e-hentai.org/watched?f_search=[りむちゃんち (うにクリームコロッケ)] ニヤニヤ教授のあま責めごときに負けないが!? (ブルーアーカイブ) [中国翻訳] [DL版]

Edit: Accessing directly through the link works fine, but issues arise when entering keywords in the search on the "Watched" page.


This post has been edited by 小白-白: Oct 31 2024, 04:27

When attempting to search for specific keywords on the "Watched" page, a 403 error occurs.
Perhaps there is a separate restriction on the Watched page. I hope it can alert users in the same way as the main page search.

For example:
https://e-hentai.org/watched?f_search=[りむちゃんち (うにクリームコロッケ)] ニヤニヤ教授のあま責めごときに負けないが!? (ブルーアーカイブ) [中国翻訳] [DL版]

Update: Accessing directly through the link works fine, but issues arise when entering keywords in the search on the "Watched" page.

Based on my tests, it seems that including the keyword "?" in the search will result in a 403 Forbidden error.

But since the multiframe detection seems to be working, I just added a bypass to treat animated WebPs similar to GIFs for now, which is to say, don't resample them at all. Which means animated WebPs should now be supported asterisk.

Will this be limited to 10MiB or another size, or will it just be limited by the file types max size of 20MiB

Also will this apply to APNG as well or just webp

This post has been edited by Cipher-kun: Oct 31 2024, 08:50

Based on my tests, it seems that including the keyword "?" in the search will result in a 403 Forbidden error.

There were some changes in the software stack that affected the behavior of some characters in rewrites, so it's probably related to that. I'll look into it.

Will this be limited to 10MiB or another size, or will it just be limited by the file types max size of 20MiB

20 MiB.

The WebP limit is 20 MiB, like JPEG.

This makes me curious. Is there any downside here, from just a normal-user-browsing perspective? Like, just scrolling through a gallery (MPV or normal) and hitting an excessive number of these?

Right now, to pick some random images just to have numbers to play with... Okay. A ~4k PNG source says it's 8MB, but MPV shows a scaled down 1280x 150KB JPG. Another one, ~2k PNG source 5MB, scaled to 1280x 350KB JPG. Obviously different images have different ratios etc, but the end result is that simply scrolling through a gallery is pretty "light", regardless of how high or low quality the sources are. Or to put it another way, there's a rough upper threshold for what will be served by default. (At least unless you go into settings and opt-in to bigger sizes, click the download source link, etc. But at that point you've made a decision anyway.)

If 20MB is the limit for these and they bypass resampling, then if someone made a gallery with a hundred of these, they'd all load the original unresampled ones, right? Could that cause problems - or at least be more problematic than a gallery of more "normal" ones?

...Guess that an all-GIF gallery would be similar if they also bypass. Never thought about it; guess it makes sense. But GIFs are pretty obvious (color limits etc), so I don't think I've ever seen more than a GIF or two here or there. Beyond galleries that literally say that it's a load of GIFs in the name; you gotta go out of your way to see those. WebP look more or less "normal", so you could scroll through them without necessarily realizing it.

Not sure what the risk here would be anyway. Just someone being a dick, I guess, and making a gallery with massive non-resampled images that look like static images? Not sure if that's that common of a problem, or if it would adversely impact anything (other than be a larger bandwidth hit, and maybe eat more image limit/quota/whatever than normal).

But it's something different. And that makes me curious if that would lead to abuse.

If 20MB is the limit for these and they bypass resampling, then if someone made a gallery with a hundred of these, they'd all load the original unresampled ones, right? Could that cause problems - or at least be more problematic than a gallery of more "normal" ones?

...Guess that an all-GIF gallery would be similar if they also bypass. Never thought about it; guess it makes sense. But GIFs are pretty obvious (color limits etc), so I don't think I've ever seen more than a GIF or two here or there. Beyond galleries that literally say that it's a load of GIFs in the name; you gotta go out of your way to see those. WebP look more or less "normal", so you could scroll through them without necessarily realizing it.

They are served through H@H from the regions with plenty of bandwidth available, so it's not so much of an issue. And like you say, you could already do that with GIFs. I plan on looking into resampling them, but people would just be banned if they tried to abuse stuff like that.

There are now a number of "real" galleries uploaded by Shank, Kagoraphobia and -terry- that use the v2 image system either fully or partially. Check them out and see if you spot any issues.

https://e-hentai.org/uploader/Shank
https://e-hentai.org/uploader/Kagoraphobia
https://e-hentai.org/uploader/-terry-
https://e-hentai.org/uploader/nasu
https://e-hentai.org/uploader/Cipher-kun

Very old browsers that don't support WebP won't work with galleries that use v2 image handling, and need to be updated. For the major browsers, this would be Chrome before 2014, Firefox before 2019, and Safari before 2020. This is a known tradeoff which will not be addressed on our end.

Edit: Added nasu and Cipher-kun.

On Firefox, the space between the thumbnails is clickable when the thumbnail looks like a rectangle and is oriented horizontally. Could this be fixed?

[postimg.cc] (IMG:[i.postimg.cc] https://i.postimg.cc/6ybLbp9t/1.jpg)

[postimg.cc] (IMG:[i.postimg.cc] https://i.postimg.cc/NKy83vMT/2.jpg)



This post has been edited by ninetydollardoujin: Oct 31 2024, 23:20

On Firefox, the space between the thumbnails is clickable when the thumbnail looks like a rectangle and is oriented horizontally. Could this be fixed?

It's not a bug, that's working as intended.

Is it possible to make the "Download Resample archive" clickable again even the gallery only have original and will download original archive.
edit: nevermind I figured things out

This post has been edited by davidor: Nov 1 2024, 08:23

Is it possible to make the "Download Resample archive" clickable again even the gallery only have original and will download original archive.

Post the link to the gallery, resampled archives should still be available.

Post the link to the gallery, resampled archives should still be available.

nevermind I figured things out

This post has been edited by davidor: Nov 1 2024, 08:23

Currently keyboard navigation in mpv is a bit bugged due to how window.preload_generic only loads images 3000 pixels distance ahead, and unloads images/pages once they're 10000 pixels distance away (ahead or behind).

This means if you hit previous button enough, eventually it no longer works; you can reproduce the issue by e.g. loading mpv on page 320, hit right arrow key until 330, and then hit left arrow key; eventually it just stops working.

I think a good fix is to just load images 3000 pixels distance ahead and behind:

CODE

--- a    2024-11-02 11:29:06
+++ b    2024-11-02 11:29:19
@@ -1,19 +1,19 @@

function preload_generic(a, b, c) {
     var d = a.scrollTop;
     a = d + a.offsetHeight;
     for (var e = "image" == b, f = 1; f <= pagecount; f++) {
         var g = document.getElementById(b + "_" + f)
           , h = g.offsetTop
           , k = h + g.offsetHeight;
-        if ("hidden" == g.style.visibility && k >= d && h <= a + c)
+        if ("hidden" == g.style.visibility && k >= d - c && h <= a + c)
             e ? load_image(f) : load_thumb(f),
             g.style.visibility = "visible";
         else if ("visible" == g.style.visibility) {
             if (k < d - 1E4 || h > a + 1E4)
                 g.innerHTML = "",
                 g.style.visibility = "hidden";
             e && k >= d + 100 && h <= d + 100 && (currentpage = f)
         }
     }
}

Script to patch the function on the page:
[gist.github.com] https://gist.github.com/FabulousCupcake/d2e...2471387a93d7413

Currently keyboard navigation in mpv is a bit bugged due to how window.preload_generic only loads images 3000 pixels distance ahead, and unloads images/pages once they're 10000 pixels distance away (ahead or behind).

This means if you hit previous button enough, eventually it no longer works; you can reproduce the issue by e.g. loading mpv on page 320, hit right arrow key until 330, and then hit left arrow key; eventually it just stops working.

Can't reproduce, under what conditions does it stop loading images exactly?

It doesn't preload images when going backwards, this is by design, but it should start loading them when they enter the viewport.

What happened in this gallery?
https://e-hentai.org/g/66/9c6750a7a7/

Can't reproduce, under what conditions does it stop loading images exactly?

It doesn't preload images when going backwards, this is by design, but it should start loading them when they enter the viewport.

With clean setup, I can't reproduce it as well.
Few things I found that made the issue reappear:
• When any level of zoom out is applied
• When using the [Align Center, Scale to Fit] mode in mpv (third icon on the top right that looks like 4 horizontal lines)
• When each page is made to fit 100% viewport height (this is third-party script, so we can ignore I suppose)

Using this as test gallery: https://e-hentai.org/g/3105020/31ca0e71a2/
• Open mpv on page 1
• Hit zoom out (or switch to [Align Center, Scale to Fit] mode)
• Using the thumb navigation, jump to page 14
• Hit left, page should change
• Hit left, page stops changing

On chrome, it stops working (URL says #page12, but window.currentpage is 13, so hitting left does nothing as it makes you go to #page12 again)
On firefox, it instead jumps to weird locations and not showing the right image, it's very hard to describe.

Depending on the browser/viewport width, it may also show different pages.

Honestly I can't understand what's going on 🥴
My best understanding is the currentpage determination using the pane scrollTop against image offsetTop can be kinda janky when some previous images are not yet loaded?

This post has been edited by FabulousCupcake: Nov 2 2024, 22:02

What happened in this gallery?
https://e-hentai.org/g/66/9c6750a7a7/

No idea how you found that one seeing as it's the only one affected, but I think it had some flags messed up by a buggy query during early testing. Should be corrected now.

With clean setup, I can't reproduce it as well.
...
Honestly I can't understand what's going on 🥴
My best understanding is the currentpage determination using the pane scrollTop against image offsetTop can be kinda janky when some previous images are not yet loaded?

Hard to say if it can't be reliably reproduced, but I'll keep it in mind.