PW 3.0.18: Yet more images field upgrades!

[ryan]

Version 3.0.18 continues from last week, making major upgrades to our images field. This week we got into some of the finer details, and we've got plenty for you to look at here, as well as a screencast (at the end) to demonstrate it all.

https://processwire.com/blog/posts/more-images-upgrades/

[Martijn Geerts]

Awesome update!

But one feature request: Optional disable crops with flexible widths & heights' and enable crop sizes from 'presets'.

[cb2004]

This is what you have to love about ProcessWire. Fantastic release last week, some feedback from users, then an even better release 7 days later.

2 small requests from me. Tooltips/titles for the icons for the different views. Reset to default for the slider.

Keep up the great work team.

[szabesz]

Thank you sooooo much!

And +1 for Martijn's request

[horst]

Awesome update!

But one feature request: Optional disable crops with flexible widths & heights' and enable crop sizes from 'presets'.

Is this already in, "crop sizes from presets"? If we could have that with the core images field, it would make the croppable images obsolete, what I think would make things much easier. We only would need one images fieldtype and optionally can define "presets" or not. Wouldn't it?

+1

[ceberlin]

What I basically would need is that the ratio is fixed (and there is a minimum of height/width it can't go below).

So users can select parts from the image to crop but that crop would always fit 100% and no further cropping would apply when using the image.

[ottogal]

Great improvements, indeed!

Some minor observations, though:

(1) After opening an image field in the editor, it happens that some of the thumbnails are not cropped correctly:
https://snag.gy/zP3cVG.jpg
Switching the grid to proportional mode and back, they are displayed well.

(2) After the upload of an image the "Choose File" button is displayed wrongly (but works as intended):
https://snag.gy/SiBY91.jpg

(3) The "Choose File" button's caption is in English, even if the editor user's language is German:
https://snag.gy/8OSQyP.jpg

(4) In the list mode one image takes too much space (so you have to scroll a lot in case of many images). Why not place the green buttons inline with the filename? Like this:
https://snag.gy/ioxGDI.jpg
And it would be fine if you could even toggle on and off the display of the description fields...

But anyway, no ranting here. Kudos for the fantastic work!

[szabesz]

(4) In the list mode one image takes too much space (so you have to scroll a lot in case of many images). Why not place the green buttons inline with the filename? Like this:

https://snag.gy/ioxGDI.jpg

And it would be fine if you could even toggle on and off the display of the description fields...

I also support these, with the additional idea of turning the labelled buttons into icon only "tools" (supported with tooltips). We need room for the filenames, so the shorter the buttons are the better. Also, we should not forget the case of a single image, confined into a narrow Column Width (mine is 30%).

If we take a look at these screenshots, we can see a two glitches in my usecase:

Namely

#1 proportional grid mode: image extends beyond its column. We can adjust the preview size, however I can imagine a narrow image that cannot be made small enough to fit.

#2 list mode: transparency is not handled

[Jugibur]

So great updates, many thanks for this work!

A little cosmetic thing: 

The size of portrait images In list mode are very large and blurry even with the smallest possible slider setting. Could be confusing for customers.
Maybe limiting the longest side of an (portrait) image to a maximum to render it smaller but sharper? Besides that the proportions / sizes of portrait and landscape images are more homogenous to each other.

EDIT: Oh, 2 minutes after sending this I found the checkbox "There are older/low quality thumbnail preview images above – check this box to re-create them." 

So the blurring is gone... sorry.

Only the size for portrait images seem too big (for my eyes) – especially if you shrink the viewport – after the break they take a lot of space.

[Peter Knight]

The new images field looks amazing.  Anytime the community requests something, we get something so much better than expected. 

Reminds me a little of the alleged henry Ford quote.

If I had asked people what they wanted, they would have said faster horses.”

― Henry Ford

Back to image cropping, most of our sites use CroppableImage. Not having a cropping solution based on pre-sets in PW3 (in-built or non-native) means we can't take advantage of these V3 right now. That's OK-ish as PW3 isn't officially released yet.

I do wonder how this will develop. Will native cropping come to V3 soon and if so, will we have to rewrite all our cropping code across every site?

$image = $page->images->first()->getCrop('portrait', "width=200, height=200, quality=80");

I think Horst has done an a amazing job with CroppableImage and it's an essential default module for most of us. I completely sympathise with his sentiment that continuing development of CI doesn't make sense when the images field has breaking changes. 

Anyway, I guess what I'm ultimately saying is +1 for image cropping around predefined presets.

A year ago that I proposed something like this (last screenshot) where various preset shapes were displayed alongside the image (and callable via the API).

I'm sure there's better ways to achieve this but if Ryan or Horst or Tom needs any extra assistance, I'm more than happy to help with wireframes, mockups, or testing etc.

[PawelGIX]

For me, the ability to crop an image in Variations modal would be sufficient.

1. Thumbnails created automatically.

2. If necessary user could select and crop the image manually. Keeping the size and proportions of the original image.

The column "NOTES" should contain information about the image, eg: "Banner image - used on homepage", "The image used in the list of posts."

This information can be saved when creating thumbnails  

$img->size(100,100, 'Post image')->url

or using a GUI in the administration panel.

[tpr]

The images field is getting superb, thanks!

I may have an issue here in Lister (default, not ListerPro). Adding an image column to the columns shows no image though they worked fine before.

Might be a CSS-only issue because disabling these rules shows the image:

.gridImage__overflow > img {
    /* position: absolute; */
    /* top: 50%; */
    /* left: 50%; */
    /* transition: transform ease .3s; */
    /* -ms-transform: translate3d(-50%, -50%, 0); */
    /* transform: translate3d(-50%, -50%, 0); */
}

[Peter Knight]

The images field is getting superb, thanks!

I may have an issue here in Lister (default, not ListerPro). Adding an image column to the columns shows no image though they worked fine before.

Hi tpr

I seem to recall a similar problem before where the image was either the first or last column of your lister.

Does that seem to be the case for you?

[tpr]

No, the second column. Moving the columns elsewhere doesn't help.

On a 3.0.17 site images are OK in the lister but it's another project, maybe this is unrelated.

[init2null]

Not sure if the bug tracker is better for this or not, but I've definitely found a bug in the Image field when using SVG files. SVGs upload without error and display thumbnails, but they have no trashcan icon and are deleted when the page editor is reopened. Existing files uploaded with the old version of image are not deleted, but there's still no trashcan icon, so they can't be deleted at all.

Cropping tools don't make sense for SVGs, but it is nice to have thumbnails and a shared field for all types of images.

[adrian]

Not sure if the bug tracker is better for this or not, but I've definitely found a bug in the Image field when using SVG files. SVGs upload without error and display thumbnails, but they have no trashcan icon and are deleted when the page editor is reopened. Existing files uploaded with the old version of image are not deleted, but there's still no trashcan icon, so they can't be deleted at all.

Cropping tools don't make sense for SVGs, but it is nice to have thumbnails and a shared field for all types of images.

I think it would definitely be worth posting this as an issue on Github.

Thanks!

[init2null]

I think it would definitely be worth posting this as an issue on Github.

Thanks!

Posted. I hope that I'll be able to supply patches in the future, but this is the best I can do for now. Thanks for the guidance.

[wet]

I may have an issue here in Lister (default, not ListerPro). Adding an image column to the columns shows no image though they worked fine before.

Confirmed and reported.

[Robin S]

Echoing a comment above...

In the image field 'list' view the size difference between landscape-format and portrait-format images can be extreme. In the screenshot below the two images have the same aspect ratio but the portrait-format is rendered much larger.

Wouldn't it be better to define the thumbnail container as a square with the thumbnail centered and fitted to the container? Then each image row is an equal height.

[szabesz]

I can imagine a landscape only gallery where saving some extra space is a good thing. However, it would be nice if we could just tick a checkbox labelled "use square thumbnails", which setting could be saved so that we can adjust the view to the use case in question.

[horst]

From a photographers or images redacteurs perspective I would say that the best presentation option would be a weightened one, based upon amount of pixels!

see in the comparision image the first and second set of images: https://processwire.com/talk/topic/8367-pia-pageimage-assistant/#entry81648

This way, neither landscape- nor portrait- oriented images, nor square dimensioned ones become visually more present than the others.

[szabesz]

From a photographers or images redacteurs perspective I would say that the best presentation option would be a weightened one, based upon amount of pixels!

This approach is quite good for the front-end, leading to better design. However we seem to be talking about the back-end/admin, where graphic design is of less concern, but usability is a must. Sure, to be able to use something one also needs decent graphic design, but the back-end is not about pleasing the eye, but about pleasing the deadline

[horst]

If you have to select a lot of images out of a mass, it is of real help, if the images are presented in a way that does not visually show one sort more prominent. It was by no means design what I have talked about. It was definetly about "to get the job done as fast as possible", what can be done way faster if a redacteur does not have to abstract those massive differend presented formats when comparing images against each other.

Believe me, also if Pros in that field are able to abstract that a lot faster and better than None-Pros, - after screening 1k or 2k images, they would kiss every one who brings them a more weightened images table for their work. 

[szabesz]

[ottogal]

Bump... 

Quote

(3) The "Choose File" button's caption is in English, even if the editor user's language is German:
https://snag.gy/8OSQyP.jpg