Release: Thumbnails

[horst]

2. The manual cropping is doing strange things

Bildschirmfoto 2014-06-18 um 18.35.25.png

look at the draggable, it´s showing a "copy" of the image instead of being transparent.

Next look at the preview..it´s cut..half of the image is missing..looks like I´m out of image with the overlay

In the end it´s working fine..but it´s irritating and not really nice for the later admins..they´re not really computer cracks ^^

@Can: please can you check and report back the following?

- which PW-version?

- what are the params for this thumb (name, width, height[, options])?

- is this the same behave with all images, or only with some?

[Can]

@Can: please can you check and report back the following?

- which PW-version?

- what are the params for this thumb (name, width, height[, options])?

- is this the same behave with all images, or only with some?

PW 2.4.0

with params you mean this "vorschau-bild,150,150" ?

it seems to be with all images..all jpg

but it´s working as it should in two other installations even with same params

by the way the hover preview is working at the moment..oh..seems to work after page save

so when uploading an image the hover preview is almost hidden like overflow:hidden..it's working after saving the page again..tried it several times with same behaviour

but cropping is still not working in one PW installation..no JS errors in chrome dev tools..

[horst]

...

but cropping is still not working in one PW installation..no JS errors in chrome dev tools..

hhm, weird. - Maybe try to completly unistall / delete the thumbnail modules and do a fresh download & installation?

[Can]

same cropping issue 

[horst]

I have sent a pull request, 

thumbnail,0,100

or

thumbnail,100,0

should work now.

@Shebaz: thanks for that nice addition.

I have tried to use it but it doesn't work for me with height set to 0. I tried these settings:

1. thumb1, 0, 200
2. thumb2, 200, 0

The first works as expected, the second doesn't. It always displays the full image and when I open the crop-page I do not get an Rectangle.

-----------------------

@apeisa: Antti, I've found two minor issues:

1) When upscaling is set to false in the config.php, it isn't respected by the Rectangle. For example if you have a setting 200,300 and upscaling is set to false, the rectangle should not go smaller than 200x300, because if you allow a smaller one, the resulting image needs to be upscaled, what isn't allowed.

If you try a thumb_w0, 0, 300 and drag the rectangle smaller than 300px height (and you have set upscaling=>false) it results in a image smaller than 300 px height. This is not the expected result and may disturb layouts.

2) If I setup a total of 11 thumbnails for 3 templates:

th_max_2, 1200, 800, template3
th_max_1, 600, 400, template3
th_mid_2, 900, 600, template3
th_mid_1, 450, 300, template3
th_small_2, 600, 400, template3
th_small_1, 300, 200, template3

thumb_4, 1600, 1200, template2
thumb_3, 1200, 900, template2
thumb_2, 900, 600, template2
thumb_2, 600, 400, template2

thumb, 240, 240, template1

When on a page with template1 uploading an image it creates 11 variations, but only one is needed / used on this page.

[apeisa]

I am hoping someone could take lead on this development, it's clearly going towards much more advanced use cases than I and Marty first implemented it. I have been poor maintainer (and since this is not very important for my own projects, I will be in future too) for this module - maybe you horst could take lead on this? I would start by forking this and creating the clear naming convention for this module (thumbnails ... cropimages is just messy).

[horst]

Oh! - Antti, many thanks for asking me, - but due to my lack of css and js knowledge I would not do it alone. Maybe you / we can ask Owzim if he is interested in this too?

[apeisa]

Sure, Owzim, or any other fellow who wants to contribute are welcome. 

[peterfoeng]

Hi,

I am interested if you guys allow me to help

[horst]

@peterfoeng: this is great. I have seen that you already sent a pull request that should solve one or two issues. (I haven't tried it yet)

The development and maintaining of this is open to all but write access to the repo should be limited to few people only I think. In the past Owzim and I have successfully and efficiently colaborated on some enhancements to the thumbnails module and he has good skills in js and css. Therefor I really would like if he join in here. Regardless of this, any help and contribution is highly appreciated.

The best way to go, (I think), would be to do this for the current module:

 - PullRequest from PeterFoeng

 

And after that we should start a fork with:

1) creating the clear naming convention for this module, like Antti has suggested (and Owzim).

2) Actually pending is an enhancement to the images naming scheme that supports custom-suffixes and assistant method(s) to use that. After we know how it is finally implemented in Pageimage we will use this in the new fork of Thumbnails module. That allows us to strip out hooks and code for deleting variations. (this is delegated to the core pageimage by the custom-suffixes)

3) Also pending is an enhancement to the imagesizer that allow a "crop before resize" manipulation with individual and exact coordinates. (The default behave is first resize and crop after) With this supported, the thumbnails module can delegate the complete imagemanipulation to the ImageSizer. This will allow to further deleagte it to any dropped in PageimageSizerModule without any additional interaction. If you decide to use another image rendering engine (currently only the PageimageSizerImagick is available) you simply install this and it will work for all image variations, regardless if they are requested by the core Imagesizer or by the thumbnails module or by any other future third party module.

fixing known issues:

4) I have tried to use the settings with 0, but it doesn't work for me with height set to 0. I tried these settings:

1. thumb1, 0, 200
2. thumb2, 200, 0

The first works as expected, the second doesn't. It always displays the full image and when I open the crop-page I do not get an Rectangle.

5)  When setup thumbs bound to templates, uploading a new image to a site with one of these templates creates also variations that are only bound to other templates

6) When upscaling is set to false in the config.php, it isn't respected by the CropRectangle. For example if there is a setting 200,300 and upscaling is set to false, the rectangle should not go smaller than 200x300, because if a smaller rectangle is allowed, the resulting image would need to be upscaled, what isn't allowed!

Make the CropRectangle respect / reflect this.

After these steps we should try to implement some of the requests already posted here:

 - thumbnails admin Grid View

 - support for Retina Variation @2x

 - copy cropped variation to other field(s) / using it within RTEs

 - and others that I haven't recognized yet

Edited June 23, 2014 by horst

[Pete]

Is this working with latest PW dev?

I'm getting all sorts of weird errors like Method Pageimage::getThumb does not exist or is not callable in this context

This was working before I upgraded so I guess something is wrong?

[Pete]

Okay, that was slightly freaky but following the last PW update I had to uninstall all the modules, delete the Admin/Pages/Image Crop page and reinstall the whole module to get it working again.

I'm hoping it was just a freak occurrence but would merit further testing before PW 2.5 is released.

[Manfred62]

Okay, that was slightly freaky but following the last PW update I had to uninstall all the modules, delete the Admin/Pages/Image Crop page and reinstall the whole module to get it working again.

I'm hoping it was just a freak occurrence but would merit further testing before PW 2.5 is released.

hmm, since last update to 2.4.5 there are other odd things (e.g. theme switching). Could be the same reason? Maybe Ryan can take a look at this.

[Marty Walker]

It's not working (for me) if I install it through the Modules tab but does if I download it from github and install it manually. Running 2.4.5 locally.

[teppo]

Okay, that was slightly freaky but following the last PW update I had to uninstall all the modules, delete the Admin/Pages/Image Crop page and reinstall the whole module to get it working again.

I'm hoping it was just a freak occurrence but would merit further testing before PW 2.5 is released.

I'm getting this right now (right after updating from 2.4.3 to 2.4.5), so it's definitely an outstanding issue. Will have to dig in to see what's going on..

Edit: Just guessing, but could this be related to this commit and the part about "6) Convert Fieldtype modules to load on-demand rather than all at boot"? Looks like after the update when InputfieldCropImage runs, FieldtypeCropImage hasn't been init'd yet.. which obviously results in getThumb() not being available.

Anyway, will have to debug more.

Edit 2: Whether or not that was the issue, I've solved it locally by making sure that FieldtypeCropImage is loaded with InputfieldCropImage. I can't uninstall the module or try other tricks on this site, as it's already in production -- I'm assuming that Antti or Ryan will dig out the real reason (and fix) for this, but in the meantime this works for me:

Index: InputfieldCropImage.module
===================================================================
--- InputfieldCropImage.module  (revision 7702)
+++ InputfieldCropImage.module  (working copy)
@@ -13,7 +13,8 @@

        public function init() {
                parent::init();
-
+               // make sure FieldtypeCropImage is loaded
+               $this->modules->get("FieldtypeCropImage");
                //default settings
                $this->set('thumbSetting', 'thumbnail,100,100');
        }

Edited July 2, 2014 by teppo

[Can]

Got another thing 

Just tried to upload an animated gif. First it's not uploading properly, means the bar stays at 100% and will not go further until saving the page.

The gif is then showing correctly but I get an error at the very top of the page

Warning: imagecolorsforindex(): Color index 126 out of range in /Users/admin/Can/htdocs/processwire/yogalounge/wire/core/ImageSizer.php on line 279 Warning: imagecolorsforindex(): Color index 126 out of range in /Users/admin/Can/htdocs/processwire/yogalounge/wire/core/ImageSizer.php on line 279

Just commented the line out and it's working

279: //$transparentColor = $transparentIndex != -1 ? ImageColorsForIndex($image, $transparentIndex) : 0;

Created a normal image field (without CropImage) without this error.

At the moment everything seems to be fine with this hacky fix, but I don't even know what this line is doing..

By the way, still got my weird cropping issue :/

[horst]

@Can: This line inspects your gif image for a transparent color (index). The Errormessage says that the image has a flag that told the function its transparent color index is the color at position 126 in the colorpalette. But the colorpalette seems not to have that much elements.

Can you send me this (original) image so that I can inspect it? (info at nogajski dot de)

To comment that line will destroy transparency in GIFs. So this is not an option. Maybe we need to do more in depth inspection for gifs if they have set a flag for transparent colors. But also it is the first time that someone report such an error. Sounds to me like a sort of inconsistent gif image.

[Can]

Thanks for clarification Horst

It's actually not transparent, at least not visible though.

Of course this line wouldn't be there without purpose hehe

But as I'm not having any other gifs at the moment I'll leave it commented for now.

[horst]

When trying to resize this image it seems to have a transparent color at index 126. But it hasn't one. To avoid an errormessage with those inconsistent gif images we can suppress errors from the ImageColorsForIndex function by precede them with an @ char:

    $transparentColor = $transparentIndex != -1 ? @ImageColorsForIndex($image, $transparentIndex) : 0;

Calling ImageColorsForIndex with an inconsistent $transparentIndex returns FALSE, so with the next line in code both cases, FALSE and 0 (zero) work as needed:

    if(!empty($transparentColor)) {

I will send have sent a PR to Github.

@Can: commenting the line is not necessary

Edited July 14, 2014 by horst

[Can]

Thanks to you Horst it's not needed anymore right 

[ceberlin]

Sometimes the thumbs appear cropped on hovering the thumbs links during page-edit.

Maybe some css z-index or overflow:hidden thing. - I am using the PW dev version.

Do you need a screenshot example?

Is there something you can do about it? 

(Sorry this was mentioned already earlier in this thread. My post can be deleted, if you wish.)

[KentBrockman]

Is there any chance to get the predefined size of the image to crop?

Something like getThumb('foo')->width;

Background, if there is no image uploaded i want to display a placeholder in the given size.

[horst]

As you define the sizes by yourself when setting up a field, you may add this manually into the template code where needed.

But you can also get it programmatically like interrobang has done it here: https://processwire.com/talk/topic/4437-delete-orphaned-filesimages-from-siteassetsfiles/#entry43750

search for this lines:

                    $crops = $field->getArray();
                    $crops = $crops['thumbSetting'];
                    $crops_a = explode("\n", $crops); // ie. thumbname,200,200 (name,width,height)

[renobird]

I've been running an early version of this module for a while, and just haven't kept up with development — but WOW!

Nice work all, this is really great!

Just wanted to mention that there are still issues with the module if used on the user profile page.

Running the latest PW dev and the latest version of Thumbnails.

[horst]

@renobird: Do you also have installed PiM? Together with PiM installed, you can store the used crop rectangle coords permanent by just add this to your site/config.php

$config->imageManipulatorOptions = array(
	'thumbnailCoordsPermanent' => true
);