Will FMP18 FILL a container field with a picture, rather than FIT it

[Slater]

Hi All,

Apologies for perhaps being in the wrong part fo the forums for this query!

I'm on FMP16 right now, and I've a container field that I use to display square pictures of people. Due to different layouts, the container is landscape on one, and portrait on another (ie wider on one, and taller on another). Because the only option in FMP 16 is to FIT the image, when the container is wider than tall, either the image is distorted or there are gaps on the sides, depending on whether I've got the 'maintain  proportions' box checked or not. And similarly, when the container is taller, then the image is either distorted or there are gaps on the top and bottom.

What I'm after is being able to FILL the container, so that whilst I loose a bit of the image on the sides or tops, the container is filled without distortion. Is this possible with FMP 18? (If there's a work around for FMP 16 I'd love to know it, but I don't think there is!!)

Many thanks in advance 

 

[Fitch]

Possibly you could make use of the GetThumbnail function. It's available in any .fmp12 version.

https://fmhelp.filemaker.com/help/18/fmp/en/index.html#page/FMP_Help%2Fgetthumbnail.html

[Slater]

Thanks but sadly that doesn't work. The function just resizes the image with the same proportions, so it effectively changes the pixel count but no the aspect ratio. And so because of this, when I show that thumb in the layout, I have the same problems as before

[comment]

Perhaps you can use a web viewer to display the image. IIUC, setting the CSS object-fit property to cover should achieve the requested resizing. 
https://developer.mozilla.org/en-US/docs/Web/CSS/object-fit

[Slater]

Thanks Comment.

It's a portal where each person has a portal row, so I have to keep it in FM. And in some layouts the best shape for the container is tall, and in some other layouts it's wide ... and I guess I can't have Fill as things stand.

I've been researching it a bit, and here's an old post that sums it up very well. It can be done for a graphic fill, but not a container  https://community.filemaker.com/en/s/idea/0870H000000fyddQAA It's from 3 years ago, and so whilst I think it's the most sensible thing in the world, and something that it's crazy not to have, I guess Filemaker don't think the same way!

It's one of those ones where I think everyone must have the same issue, but I guess not. I'll try to let it go 🤯

Here's another one post where someone from FM seems to be saying that it can't happen: https://community.filemaker.com/en/s/question/0D50H00006ti3ctSAA/how-do-i-change-how-an-image-displays-in-a-container-field

I wish I could think of a workaround, but because I have the need for a taller container sometimes, and a wider container other times, I guess not 😱

[comment]

16 minutes ago, Slater said:

I have to keep it in FM

You cannot keep in it FM - but perhaps you can use a plugin, e.g. https://baseelementsplugin.zendesk.com/hc/en-us/articles/206609078-BE-ConvertContainer

Without this, you would have to process the images in an external application and store the results in additional container fields.

 

[Fitch]

15 hours ago, Slater said:

Thanks but sadly that doesn't work. The function just resizes the image with the same proportions, so it effectively changes the pixel count but no the aspect ratio. And so because of this, when I show that thumb in the layout, I have the same problems as before

I just tested this and it seems to work. Change the display field to "crop to frame" rather than reduce/enlarge, and then use GetThumbnail to set the image size to slightly bigger than the field's dimensions. You said you didn't want to change the aspect ratio.

[Slater]

Thanks Comment and thanks Fitch.

Great idea to check out plug ins. I've had a quick look.

Also, really cool of you to have got back to me Fitch. I've had a play with this, and this won't work if the original picture is smaller than the container. In that case, it seems to me, GetThumbnail won't work, which is why it didn't seem to be working for me, when I checked it out. The particular layout that I was using meant that it didn't appear to be working.

But if the original is larger, then it does!!

Yay, thanks Fitch, that seems to do the job ... now to resize all the originals that are too small 😳🤓

[Slater]

Also, just FYI there are some problems with this if the images are different sizes. GetThumbnail only returns a consistently sized thumbnail when the originals are the same size. So if your library of images are different sizes, then you will need to plug in different values to the GetThumbnail function.

The toss up being that this will only work seamlessly if all of you images are exactly the same size. (It's better than the default situation though, so I'm not complaining!) 

[comment]

Earlier I was confused by your saying:

On 1/14/2020 at 7:29 PM, Slater said:

The function just resizes the image with the same proportions, so it effectively changes the pixel count but no the aspect ratio.

But in fact you do NOT want to change the aspect ratio, so that's not a good reason why the GetThumbnail() function wouldn't work for you. I might be reluctant to use it for reasons of image quality, but if this is for on-screen display only (and there is no requirement for a hi-res on-screen display), it can work.

 

On 1/15/2020 at 1:36 PM, Slater said:

there are some problems with this if the images are different sizes.

There should be no problems with this because the target size (or rather the size limits, if you're using  the GetThumbnail() function) can be calculated using the source image dimensions as the input. These dimensions can be retrieved using the GetHeight() and GetWidth() functions as well as the GetContainerAttribute() functions.

If you like, you can make this completely dynamic by giving the target container an object name and getting its dimensions via the GetLayoutObjectAttribute() function. Then the calculation can automatically adjust the size to fit the size of the target container on the current layout (but then it must be unstored).

 

On 1/15/2020 at 11:52 AM, Slater said:

now to resize all the originals that are too small

I would be careful with that. Resizing an image results in permanent loss of quality.

 

Edited January 18, 2020 by comment

[Slater]

On 1/17/2020 at 9:05 PM, comment said:

There should be no problems with this because the target size (or rather the size limits, if you're using  the GetThumbnail() function) can be calculated using the source image dimensions as the input. These dimensions can be retrieved using the GetHeight() and GetWidth() functions as well as the GetContainerAttribute() functions.

If you like, you can make this completely dynamic by giving the target container an object name and getting its dimensions via the GetLayoutObjectAttribute() function. Then the calculation can automatically adjust the size to fit the size of the target container on the current layout (but then it must be unstored).

 

Thanks Comment, as ever! Apologies for my late reply, I've been tied up with something.

That's such a cool way to go about it. I think I could create three outputs, 3x2, 2x3 and 1x1, and then just standardise all containers so that they're one of those three.

Thanks for helping me figure this, cheers