[X] My Assistant

Thanks, it works now, but there is a problem with the style of the buttons in MPV.
PS: Image Size Settings - Horizontal is set to 700px[/img]

Working as intended, it would have to limit the width of the images (or at least the bars) if we wanted to prevent overlaps in all cases.

And is it possible to add a scroll bar for MPV?

You can add it with a user style if you want it, but it won't be added by default or as an official option as it would probably break stuff if people move it around too quickly.

Working as intended, it would have to limit the width of the images (or at least the bars) if we wanted to prevent overlaps in all cases.

It seems I didn’t express myself clearly. What I mean is:
If I set a maximum width for the image, then neither the image nor the button should exceed the set value, just like before (main site, the second part in the image).
But now, the button exceeds the width of the image, making it harder to click (test site, the first part in the image).

It seems I didn’t express myself clearly. What I mean is:
If I set a maximum width for the image, then neither the image nor the button should exceed the set value, just like before (main site, the second part in the image).
But now, the button exceeds the width of the image, making it harder to click (test site, the first part in the image).

Oh, right. Yeah, that's a trivial fix, try it now.

Oh, right. Yeah, that's a trivial fix, try it now.

It works now, thanks!

Wanted to ask if the change of options for displaying thumbnails rows in gallery from 4/10/20/40 to 4/8/20/40 was intentional?
Is it reasonable to ask for option for having 10 rows again?

Wanted to ask if the change of options for displaying thumbnails rows in gallery from 4/10/20/40 to 4/8/20/40 was intentional?

This is intentional, because we'll have two different tilesets that are 20 and 40 thumbs each, so all thumbnails-per-page options should be divisible by 20 and 40.

PS: If people want to OCD about "then why not 25 and 50 thumbs per tileset" because they really want 100 per page, it's because for 200x thumbs, while 25 is only divisible by 5, 20 is divisible by 2, 4 and 5. Which means that with 25 per page, there will be a row of leftover thumbs at all narrower screen widths, while with 20, we avoid that with all widths except those that result in 3 thumbs per row. Similarly for 100x thumbs, while 40 is divisible by 2, 4, 5, 8 and 10, 50 is only divisible by 2, 5 and 10. (Disregarding numbers above 5 for 200x thumbs and 10 for 100x thumbs since we never go above that number of thumbs per row).

The "ideal" base factor of thumbs per page would be 60, which is divisible by 2, 3, 4, 5, 6 and 10. But that's a lot of thumbs to load by default seeing as most people just jump to page three at most, and it still doesn't result in 100 per page.

This is intentional, because we'll have two different tilesets that are 20 and 40 thumbs each, so all thumbnails-per-page options must be divisible by 20 and 40.

PS: If people want to OCD about "then why not 25 and 50 thumbs per tileset" because they really want 100 per page, it's because for 200x thumbs, while 25 is only divisible by 5, 20 is divisible by 2, 4 and 5. Which means that with 25 per page, there will be a row of leftover thumbs at all narrower screen widths, while with 20, we avoid that with all widths except those that result in 3 thumbs per row. Similarly for 100x thumbs, while 40 is divisible by 2, 4, 5, 8 and 10, 50 is only divisible by 2, 5 and 10. (Disregarding numbers above 5 for 200x thumbs and 10 for 100x thumbs since we never go above that number of thumbs per row).

Understandable, Have a Nice Day (IMG:[invalid] style_emoticons/default/smile.gif)

Which gallery? Can you take a screenshot?

Oops, my mistake. Original is now on the left, not right like before. It works as expected. Thanks.

The changes are now fully live. Again, if you are using outdated third party scripts/apps/programs, they may need an update to work properly.

Anyone who wants to preview a gallery that uses v2 image handling (for verifying script compatibility or whatnot) can check out this one. Nevermind the ponies, it's a 10+ year old set of test images I use because they cover a wide range of thumbnail dimensions.

The changes are now fully live. Again, if you are using outdated third party scripts/apps/programs, they may need an update to work properly.

Anyone who wants to preview a gallery that uses v2 image handling (for verifying script compatibility or whatnot) can check out this one. Nevermind the ponies, it's a 10+ year old set of test images I use because they cover a wide range of thumbnail dimensions.

Hello, the archiver_key is no longer present on the API responses. Is this intended? Is it no longer needed?

Hello, the archiver_key is no longer present on the API responses. Is this intended? Is it no longer needed?

.

It was removed since it is not required anymore.

Anyone who wants to preview a gallery that uses v2 image handling (for verifying script compatibility or whatnot) can check out this one.

I have a few questions to consult:

1. The format of the cover thumbnail link in the test gallery (https://ehgt.org/w/00/497/82198-4uzcjt52.webp) differs greatly from the current one (https://ehgt.org/ad/d6/add6fcbb742beb9ca3e64e942216c7a90ee920e6-843612-850-1200-png_250.jpg) and isn’t actually in true webp format. Will this be changed when the new system officially goes live?

2. From the test gallery, it appears that the resampled images retain the same format as the original images. Will this remain the case in the future, or will all resampled images be converted to webp format?

This post has been edited by 小白-白: Oct 28 2024, 15:41

1. The format of the cover thumbnail link in the test gallery (https://ehgt.org/w/00/497/82198-4uzcjt52.webp) differs greatly from the current one (https://ehgt.org/ad/d6/add6fcbb742beb9ca3e64e942216c7a90ee920e6-843612-850-1200-png_250.jpg) and isn’t actually in true webp format. Will this be changed when the new system officially goes live?

Oh, that's a good catch, it actually used the wrong file format since the cover happened to be a v1 image. This should be fixed now, thanks.

The format for WebP cover URLs is final and is unlikely to change any further.

2. From the test gallery, it appears that the resampled images retain the same format as the original images. Will this remain the case in the future, or will all resampled images be converted to webp format?

v2 images (those first uploaded on the new uploaders) will use WebP both for thumbnails and resamples. v1 images (those originally uploaded on previous uploaders) will continue using JPEG for resamples until they are converted to v2 images, which may or may not actually happen, and definitely not for some time.

The format for WebP cover URLs is final and is unlikely to change any further.

Got it, thanks.

v2 images (those first uploaded on the new uploaders) will use WebP both for thumbnails and resamples.

However, the first image in the test gallery was originally in PNG format, and the resampled version (1280px) is in JPG format, not WEBP. Is this an error?

However, the first image in the test gallery was originally in PNG format, and the resampled version (1280px) is in JPG format, not WEBP. Is this an error?

That is working as intended, the PNG and JPEG images in that gallery are v1 images since they were added to other galleries before the new uploaders went live, so for now it will keep resampling those as JPEG even if they are added in new galleries.

I made a new version of the example gallery with a fresh PNG as the cover, so you can see how it works in practice.

Does the v2 system support animated WebP? If so, can we have a test image as well?

There's no tradeoff; the amount of file requests are cut by a factor of 20 or 40 and the total filesize is significantly smaller, but there is no decrease in flexibility for how the thumbs are placed. There's just some additional complexity on the backend and in the code that makes the HTML.

A tileset for 200x thumbs looks like this, then it just uses some CSS tricks with basic math to calculate the offsets and dimensions for each individual thumbnail to make it look like this in the browser.

Incidentally, we've been doing this for 100x thumbs for years.

Unfortunately, the thumbnail display as a style background breaks down when the thumbnail element is resized to any size in the user style, as I feared.
Tenboro said “there is no trade-off”, but there certainly was a trade-off in the above sense.
I have actually checked it out in the gallery below.
https://e-hentai.org/g/3102573/cd29206286/

I have included it here as a report on the discrepancy in perception of trade-offs between you and me.
I would be grateful if there was some sort of remedy for this, but if it is technically difficult then I don't mind leaving it as it is.

Again, thank you for the conversation with you.

Does the v2 system support animated WebP? If so, can we have a test image as well?

It should support it in the same sense it supports animated PNG, which is to say not really, but there are some improvements in the image processing backend to detect images with multiple frames, so it might be improved in the future.

Not sure I ever came across an animated WebP in the wild, though, so it's kinda hard to test.

Unfortunately, the thumbnail display as a style background breaks down when the thumbnail element is resized to any size in the user style, as I feared.

You'd probably have to play with the background-size property to compensate if you change the div geometry, but I haven't really looked into it.

The changes are now fully live. Again, if you are using outdated third party scripts/apps/programs, they may need an update to work properly.

Anyone who wants to preview a gallery that uses v2 image handling (for verifying script compatibility or whatnot) can check out this one. Nevermind the ponies, it's a 10+ year old set of test images I use because they cover a wide range of thumbnail dimensions.

Yeah, v2 is going to be disastrous for me due to WebP, particularly with it being used for downsampled images as well as thumbnails (my preferred offline reader has no support, and avoiding WebP was a big reason I stuck with EH over another site). I don't see any obvious way of using the API to recreate the frontpage/search results to pass through a preprocessing step or some other workaround.

Yeah, v2 is going to be disastrous for me due to WebP, particularly with it being used for downsampled images as well as thumbnails (my preferred offline reader has no support, and avoiding WebP was a big reason I stuck with EH over another site). I don't see any obvious way of using the API to recreate the frontpage/search results to pass through a preprocessing step or some other workaround.

Download the originals for offline viewing then. We waited five years after all major browsers started supporting WebP, and at this point it is near-ubiquitously supported by all maintained software, with native support in Win 10 and 11, so it is time to make the switch.

WebP is 30-50% smaller than JPEG at the same quality based on my own testing - and for the record, we aren't prioritizing making the files smaller, instead the quality has been set much higher.

JPEG is from 1992, and is anachronistic to say the least in 2024. It belongs with the rest of the tech in [old.reddit.com] this video.