[X] My Assistant

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.

I don't like webp at all, preferring jpg, but now that most sites are all converted to webp, there's no choice.
Try Bandiview for PC and Perfect Viewer for mobile.

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.

# Proposal
I propose that for the thumbnail image, it should be an img element instead of a div element background style, as shown below.
Technically, this is achieved by cropping with object-view-box. (object-view-box is not applicable to images as background styles)
The change from div to img allows arbitrary resizing of the thumbnail element.

I have actually written a user script that converts divs to img and run it on a test pony gallery to confirm that it works.
I don't know how valuable this suggestion would be to users other than myself, but I would appreciate your consideration of modifying the backend code responsible for the DOM structure of the gallery pages.


## a) Current state
thumbnail image as background style for div element (trimmed by background-position)
- Thumbnail element: div
- Image URL specification: specified by style attribute [ background ] of div element
- Trim method: background-position

### Sample

CODE

<a href="#page1"><div style="height:h;width:w;background:transparent url(tiledThumb.webp) -0px 0" no-repeat></div></a>
<a href="#page2"><div style="height:h;width:w;background:transparent url(tiledThumb.webp) -200px 0" no-repeat></div></a>
<a href="#page3"><div style="height:h;width:w;background:transparent url(tiledThumb.webp) -400px 0" no-repeat></div></a>

## b) Proposal
set thumbnail image as img element (trimmed with object-view-box)
- Thumbnail element: img
- Image URL specification: specified by src attribute of img element
- Trim method: specified by style attribute [ object-view-box ] of img element

### Sample

CODE

<a href="#page1"><img src="tiledThumb.webp" style="object-view-box:inset(0 2400px 0 0px);width:w;height:h;"></a>
<a href="#page2"><img src="tiledThumb.webp" style="object-view-box:inset(0 2200px 0 200px);width:w;height:h;"></a>
<a href="#page2"><img src="tiledThumb.webp" style="object-view-box:inset(0 2000px 0 400px);width:w;height:h;"></a>

*) Each value of object-view-box:inset() in the above example is a placeholder assuming that the tiling thumbnail is composed of a single line of “200px width × 13 images”.
If possible, it would be nice if we could also crop the “height direction” of the individual thumbnails at object-view-box:inset(). Currently the DOM does not have that information, so it is fixed at 0 in the user script.


## Reference
A function for user scripts that aims to convert div to img.
(written as a proof of concept before proposing it)

CODE

/**
* convertDivToImgForTileThumb
*
* - For tiled thmubnail system
* - Convert div element to img elements that are tolerant of element resizing.
*/
function convertDivToImgForTileThumb() {
  const [THUMB_WIDTH, _THUMB_HEIGHT] = [200, 300];
  
  // 1) targetElement extraction
  const targetElementList = document.querySelectorAll('#gdt > a > div');

  // 2) targetElement Grouped by thumbnail URL
  const urlReg = /(?<=url\().+(?=\))/;
  const groupedtargetElementList = Object.groupBy(targetElementList, e => {
    return e.getAttribute('style')
      .split(';')
      .at(-1)
      .match(urlReg)[0]
  });
  // console.log(groupedtargetElementList);

  // 3) Convert div to img by group (add img / remove div)
  Object.entries(groupedtargetElementList).forEach(([tileThumbURL, elementList]) => {
    if (!tileThumbURL.startsWith(`https://praogxqcch.hath.network`)) return;
    
    const totalWidth = THUMB_WIDTH * elementList.length;
    elementList.forEach((e, i) => {
      // OMIT:Vertical trimming is not supported (Fixed to 0). Because, height information is not included in DOM.
      const style = `object-view-box:inset(0 ${totalWidth - (THUMB_WIDTH * (i+1))}px 0 ${THUMB_WIDTH * i}px)`;
      e.insertAdjacentHTML('beforebegin', `<img src="${tileThumbURL}" style="${style}">`);
      e.remove();
    });
  });
};

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.

Ah, I though it was going to be a complement to GIF, so the plan is still to use WebM for that?

One more thing, given WebP's 16k dimension limit, will images that may exceed the limit even after resampling (webtoons may have ridiculous resolution) fallback to JPEG for resamples?

I propose that for the thumbnail image, it should be an img element instead of a div element background style, as shown below.
Technically, this is achieved by cropping with object-view-box. (object-view-box is not applicable to images as background styles)
The change from div to img allows arbitrary resizing of the thumbnail element.

[caniuse.com] https://caniuse.com/mdn-css_properties_object-view-box
It's not even supported by Firefox, I doubt it will be considered.

This post has been edited by aklfhl: Oct 29 2024, 05:18

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.

Got it, thanks.

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

This is an animated webp image (2000*2828px), can you upload this file to the test gallery for testing?

[img.moedog.org] https://img.moedog.org/images/2024/10/29/106700785.webp

This post has been edited by 小白-白: Oct 29 2024, 11:00

I propose that for the thumbnail image, it should be an img element instead of a div element background style, as shown below.
Technically, this is achieved by cropping with object-view-box. (object-view-box is not applicable to images as background styles)
The change from div to img allows arbitrary resizing of the thumbnail element.

We won't fundamentally change the DOM just to make it easier to do third party scripting. And as aklfhl says, that element has woefully inadequate browser support.

CODE

This feature is experimental. Use caution before using in production.

This is an animated webp image (2000*2828px), can you upload this file to the test gallery for testing?

https://e-hentai.org/g/3105613/503742fb29/

Works about as well as expected, which is to say you have to get the original to see anything past the first frame, but it did detect that there were multiple frames.

CODE

This feature is experimental. Use caution before using in production.

https://e-hentai.org/g/3105613/503742fb29/

Works about as well as expected, which is to say you have to get the original to see anything past the first frame, but it did detect that there were multiple frames.

the webp in 3105613 in mpv doesn't do the animation as expected. I was using chrome(up to date).

edit:neither animate in default view, I'm not sure is that my problem or some magic happened?

This post has been edited by Lady_Slayer: Oct 29 2024, 09:45

the webp in 3105613 in mpv doesn't do the animation as expected. I was using chrome(up to date).

By "about as well as expected" I meant it wouldn't animate because it was resampled, just like animated PNGs.

The toolchains the site uses don't seem to have any support to resample animated WebPs (even Google's own libwebp-tools seems lacking), at least not without a lot of faff like splitting and reassembling the frames.

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.

I just added a bypass to treat animated WebPs similar to GIFs for now, which is to say, don't resample them at all.

For now, this is also a good solution, and the user experience will be better than GIFs.

that is fantastic. Thank you so much Tenbo!

Also missed this:

One more thing, given WebP's 16k dimension limit, will images that may exceed the limit even after resampling (webtoons may have ridiculous resolution) fallback to JPEG for resamples?

It's not much of an issue since images are limited to 20000 x 20000 anyway, but if a source image is taller than 16363 pixels, it's just resampled to that.

Also missed this:
It's not much of an issue since images are limited to 20000 x 20000 anyway, but if a source image is taller than 16363 pixels, it's just resampled to that.

Nice, thanks for the efforts!
The v2 system looks promising, looking forward to it.

We won't fundamentally change the DOM just to make it easier to do third party scripting. And as aklfhl says, that element has woefully inadequate browser support.

Thank you for your reply.
Strictly speaking, the purpose of my proposal is not to "make it easier to run user scripts" but to "make it possible to specify element sizes using user CSS alone."

I did not realize that browser support for the target style was insufficient.Thanks to aklfhl for pointing that out.
Personally, I was able to achieve my goal with the user script I presented earlier.
I think I'll leave it at that on this issue.

Thanks for talking to me.

I just added a bypass to treat animated WebPs similar to GIFs for now, which is to say, don't resample them at all.

I just noticed an issue: in gallery 3105613, the original images are displayed as expected during viewing, but in the Archive Download interface, it's still possible to download the resampled images. Is this issue specific to this gallery only, and will future galleries work the same way as with GIFs?

I hope not to see this video codec masquerading as an image codec added. It's full of security risks.

I just noticed an issue: in gallery 3105613, the original images are displayed as expected during viewing, but in the Archive Download interface, it's still possible to download the resampled images. Is this issue specific to this gallery only, and will future galleries work the same way as with GIFs?

It needs some minor work to be recognized as a non-resizeable filetype everywhere, but I'll probably get around to fix it tomorrow.

I found that the download speed using http from the two urls “encvgvvzml.hath.network” and “taopjgvkhp.hath.network” is too slow, and the 2-thread or single-thread download speed is less than 50KB/s.Other links such as “cipvxqwzvk.hath.network”, “roxysxyymp.hath.network” and “xecemudyvf.hath.network” have normal speeds, usually above 1MB/S.These problems seem to have occurred after the domain name of the http download was changed. Is it a problem of the region and ISP?

I'm also having issues with those two these past 2 days so you're not alone. I'm unsure if the speeds were normal prior to this since the url isn't something I normally pay attention to.

the webp changes will be only for thumbnails and resamples, right? it will keep serving png and jpeg when you choose to download the original files?

I just noticed an issue: in gallery 3105613, the original images are displayed as expected during viewing, but in the Archive Download interface, it's still possible to download the resampled images. Is this issue specific to this gallery only, and will future galleries work the same way as with GIFs?

This should be fixed in general now, but let me know if you find a way to convince the site to provide a resample for this file. I uploaded a new version of the animated webp test gallery with another file to enable the resample options.

the webp changes will be only for thumbnails and resamples, right? it will keep serving png and jpeg when you choose to download the original files?

The originals will still be available as before, so unless the uploaded originals are WebPs, then yes.

This should be fixed in general now, but let me know if you find a way to convince the site to provide a resample for this file.

Sounds good. Perhaps we could try using the [www.php.net] ImageMagick extension to perform resampling on animated WebP. Here is a sample website: [moedog.org] https://moedog.org/tools/webp_resample/, and here is an image resampled to 1280px: [moedog.org] https://moedog.org/tools/webp_resample/resa..._106700785.webp.

Sounds good. Perhaps we could try using the [www.php.net] ImageMagick extension to perform resampling on animated WebP. Here is a sample website: [moedog.org] https://moedog.org/tools/webp_resample/, and here is an image resampled to 1280px: [moedog.org] https://moedog.org/tools/webp_resample/resa..._106700785.webp.

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.