Automatic thumbnails for Textpattern

Bloke · Yesterday 14:23:28

Callbacks added:

(by ref) txp.image / thumbnail.params is passed the $params array and $thumbnail (the type: 0, 1, or 2) so plugins can take action only on a certain type of thumbnail access, or can inject parameters for fullsize images too.
txp.image / url / thumbnail is passed the current URL, the image object, the $params, and $thumbnail (the latter in case you want to switch on it without having to add individual handlers for each type of thumbnail).

I did some rudimentary tests and it gives some nice powers to plugins to play with the generated thumbs, and to change things.

Bloke · Yesterday 14:28:30

etc wrote #341752:

It complains about type mismatch.

That’ll probably be because of the SLIRImageLibrary interface, which will also need its signature changing.

The out of memory is probably due to a large source image. It’s not very robust with big files, which is something we can look at later. I managed to max out my hosts’ maximum 256MB php.ini setting generating a thumb on a smallish 3000px square image.

As long as it works for now, on regular size (not HD) pics, we can refine it and optimise it in future. Unless you happen to know some memory-saving tricks when creating thumbs (because class.thumb.php manages it on largish pics so we might be able to copy code over).

Bloke · Yesterday 15:59:39

Okay, I reverted the transparency tweaks I made since they broke the ability for /w400-b0e56ae/NN.ext style URLs to add backgrounds to transparent images.

I guess the patch they supplied wasn’t battle tested (or I misinterpreted it, but I did try it a few ways, including directly copying it over in case my tweaks broke it). Neither worked, so we’ll rethink it.

jakob · Yesterday 18:42:13

Thanks for all your investigations and updates. I just a did a test with the transparent images I tested before plus Philippe’s image, and then with the example exif images linked to above. Findings:

All static transparent images rendered for me with a transparent background, including Philippe’s screenshot image.
Animated transparent images show a black background. This is probably a special case where animated images are concerned.
Quality settings seem to work. The corresponding thumbs are created. In my test image I couldn’t accurately see the difference between quality="50" and quality="100", but an image diff does show they are indeed different.
Testing the exit examples linked to above: all images are correctly rotated, but images 5, 6, 7 & 8 all have a cropped thumbnail in both orientations. The portrait images have a dark band to the right for the portrait images, and along the bottom for the landscape images, and a bit of the image is cropped off. See the screenshot (source of the test images).

Bloke · Today 01:29:59

Hmmm, I can’t fathom the best place to apply this fixRotation() method. In the position it is now, it does the job but the info object seems to be overwritten. Or it just doesn’t apply the value (I can’t tell which).

If I move the function call a bit later, it still makes no difference.

There is an issue with the dimension swapper. It (wrongly) swaps the current image’s dimensions but what it really needs to do is replace the new image’s dimensions with the original image’s dimensions, in reverse. A bit like this:

// Swap height and width values if thumbnail is rotated by 90°.
if (in_array($exif['Orientation'], [5, 6, 7, 8])) {
    $this->setWidth($exif['COMPUTED']['Height']);
    $this->setHeight($exif['COMPUTED']['Width']);
}

That does indeed “work” except the resulting (landscape) image is squished in the X-axis to fit the cropped viewport (if a cropper is applied). Presumably the portrait images will be squishes in the Y-axis.

I don’t know for sure but I suspect this rescaling either needs to take place after we know what cropper is going to be applied, so we can set the wdth and height to the cropped dimensions. Or it needs to use different values – perhaps using the relative scaling factor (see SLIR.php: resizeCroppedWidthFactor()). Or maybe we need to setCropWidth() and setCropHeight() (instead of, or in addition to, the regular width and height)?

Quite what these values should be isn’t clear to me. Might just need a bit of messing around to reverse engineer which fixed values work, and then figure out where to read those values from inside the class.

Bottom line is that we need to replicate what happens in Jools’ patch to class.thumb.php, just using the variable names and image objects from SLIR. The fixRotation() method is close – very close – but the bit that sets the width and height is wrong and I can’t fathom it with the woolly head I have on right now.

If anybody has any insight with fresh eyes, be my guest. Otherwise I’ll try again tomorrow.

phiw13 · Today 06:31:20

Testing with the lasted updates, quality and the transparency support (third attempt).

quality: using quality:50 and quality:100, visually it didn’t make much difference for my landscape image, the portrait image (person against cityscape in the distance) there was a little bit of improvement in the sharpness of the face and the product image (product with blurred background) there was a more noticeable edge sharpness. The quality:100 images have a much larger file size as can be expected (2 to 3 times).
transparency: using the Sandspace UI screenshot I shared the other day (.webp format: Yesssir, no more black border! 👍Visual inspection with the macOS screen magnifier show smooth edges all around.

Note: the screenshot above was scaled from 1600px to 800px and displayed at half the size to mimic my monitor’s DPR. That way the image does renders crisply.

jakob · Today 11:12:59

Looks like you nailed it. Well done! As you say, the test images work correctly now.

Overall, it’s pretty brilliant now!

Bloke · Today 11:16:37

[Moved from wrong thread, d’oh]

Aha!

The trick is to split the calculation part that swaps the image dimension at input time, and perform the rotation later at output time. Try that and see how you get on with rotated images. It works for the 18 sample images in that set Jools posted.

It does assume that the Orientation flag is in the root EXIF data structure. I’ve heard rumour that some cameras put it elsewhere (like in the COMPUTED section, maybe?) which will knacker this up. So the more tests we can perform from a wide array of devices, the better.

Bloke · Today 11:18:13

Hah, oops. Idiot. I moved my post and updated your link. Thanks for keeping me sharp!

Bloke · Today 11:39:27

Bear in mind you can alter the cropper used in your Theme Prefs too (and maybe URL, not tried it), as a third argument. And you can split your ratios by dot, colon or ‘x’. You have a choice of three croppers:

smart
centered
topcentered

So, example crop ratios:

1×1
100×150
3×2
16:9
4.3
4.3.topcentered
3×2:centered
16×9.smart

And so on. Please test them and see the difference.

etc · Today 13:21:58

Exciting!

We might probably avoid filling/reading txp_token table, unless thumbnail tokens serve yet for something else. What is their exact purpose? Could not we check in some way that the provided ?token=... is valid, without assuming that it is written to txp_token via imageBuildURL()?

Bloke · Today 13:34:40

etc wrote #341776:

We might probably avoid filling/reading txp_token table, unless thumbnail tokens serve yet for something else. What is their exact purpose?

Only to check that the request originated from a tag or the admin side. That’s all.

If you have any better ideas for implementations, by all means go for it.

The goal is simply to stop anyone spamming the URL and creating a zillion images, filling up disk space and consuming processor resources.

How that is implemented, I have no preference.

Textpattern CMS

Textpattern CMS support forum

#181 Yesterday 14:23:28

Re: Automatic thumbnails for Textpattern

#182 Yesterday 14:28:30

Re: Automatic thumbnails for Textpattern

etc wrote #341752:

#183 Yesterday 15:59:39

Re: Automatic thumbnails for Textpattern

#184 Yesterday 18:42:13

Re: Automatic thumbnails for Textpattern

#185 Today 01:29:59

Re: Automatic thumbnails for Textpattern

#186 Today 06:31:20

Re: Automatic thumbnails for Textpattern

#187 Today 11:12:59

Re: Automatic thumbnails for Textpattern

#188 Today 11:16:37

Re: Automatic thumbnails for Textpattern

#189 Today 11:18:13

Re: Automatic thumbnails for Textpattern

#190 Today 11:39:27

Re: Automatic thumbnails for Textpattern

#191 Today 13:21:58

Re: Automatic thumbnails for Textpattern

#192 Today 13:34:40

Re: Automatic thumbnails for Textpattern

etc wrote #341776:

Board footer