Open-event-server: Speaker images not being resized correctly

Created on 4 Jan 2020  Â·  26Comments  Â·  Source: fossasia/open-event-server

thumbnail width height is set to 150px but still the image generated is of 500px

https://eventyay.com/e/423d0650/sessions/s/all

Also, if I upload an image of 320x320 px and resize width is set to 500px. It upscales the image to 500px. If the image dimension is less than target dimension, return the original image URL as is

bug codeheat

All 26 comments

@codedsun Can you please take a look

@iamareebjamal - The db values are different from what you mentioned here

thumbnail width height is set to 150px but still the image generated is of 500px

https://github.com/fossasia/open-event-server/blob/e758cfc1dc812bd0d867beed0a65f24886634158/populate_db.py#L98-L103

The admin panel shows different values. It means it is not tied to the admin settings - https://eventyay.com/admin/settings/images

And similarly, these are not stored in DB as well. There are only 2 types in DB. event and profile. And admin settings shows profile one as Profile/Speaker images

@iamareebjamal - Okay, will check for the case of 150. Thanks

@iamareebjamal - the flow is working fine. I tried to upload 2 images for 2 diff speakers

  1. with dimension
    724 × 1024

the dimension of thumbnail image is - 150*212
image

  1. with dimension
    900*750

the thumbnail image dimension - 150*125

image

What else can reproduce me this issue.?

For this

Also, if I upload an image of 320x320 px and resize width is set to 500px. It upscales the image to 500px. If the image dimension is less than target dimension, return the original image URL as is

I shall then set the thumbnail_url to originial_image_url if the following condition arrives.

Not working in production. I resized them using the manage.py method you created. Thumbnail images are of 500px

@iamareebjamal - Let me check out this on master branch then.

Try the manage.py command

The manage.py command method is not working you meant? Okay will chck

@iamareebjamal - Resized using manage.py command also, same result(https://github.com/fossasia/open-event-server/issues/6724#issuecomment-570939195). the manage.py command also uses the same celery task which is used while uploading speaker image. Both are working fine for me in dev. What else should I try to reproduce this issue?

@iamareebjamal - Ping

Will check why it didn't work in production

@iamareebjamal - One possibility would be when the values were not found, then only the else condition will execute which takes thumbnail_width_height=500

https://github.com/fossasia/open-event-server/blob/95357f2460246d3b2cd534e111f2a024aa068e70/app/api/helpers/files.py#L130-L140

What is image_sizes_type? It should be profile

@iamareebjamal - But the task runs with type speaker-image
https://github.com/fossasia/open-event-server/issues/6724#issuecomment-570913430

We have twoo image_sizes_type

  1. speaker_image
  2. event-image

That's wrong. In production, the type is profile, the same is used in the admin settings - https://api.eventyay.com/v1/speaker-image-sizes

See the type. Check on your local. What's the type

@iamareebjamal - The celery task also uses the same key speaker-image. The createdb file also creates the same and on my local also shows the same.

image

The api running on production says type profile . That's strange

It's not strange. The API just fetches the row with ID 2 regardless of type. I know it's stupid. I already opened the reimplementation issue for image resizing 1 month ago - #6641 .

For now, try to figure what should be used, profile or speaker-profile. Check where profile is being used

@iamareebjamal - yes this is the issue, I shall take that up after 1-2 issues.

https://github.com/fossasia/open-event-server/issues/6641

The API just fetches the row with ID 2 regardless of type. I know it's stupid

Also, This should be fixed then.

For now, try to figure what should be used, profile or speaker-profile. Check where profile is being used

It's speaker-image not ~speaker-profile~. I will get back to you

Also, it's strange for me that how does data in production db differs from dev db

It's pretty normal. profile was being used previously. When speaker image split from it, nobody bothered to create a migration. It's kind of tradition

@iamareebjamal - speaker-image is used everywhere in dev.

And profile isn't used?

Nopes!

OK. Wow. Then change the logic of API to fetch by type and not ID, it should fix everything

Also, use get_or_create so that if it is not created, it is saved in DB

Was this page helpful?
0 / 5 - 0 ratings