openfoodfacts / smooth-app

The new Open Food Facts mobile application for Android and iOS, crafted with Flutter and Dart

Home Page:https://world.openfoodfacts.org/open-food-facts-mobile-app?utm_source=off&utf_medium=web&utm_campaign=github-repo

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Allow to pick a price proof from your online proof gallery

teolemon opened this issue · comments

Problem

  • to avoid overload of proofs on the Open prices server, we should allow to pick a price proof from your online proof gallery, very much like we already do for regular umages

Code pointers

Part of

@teolemon cf. @raphael0202 @raphodn

to avoid overload of proofs on the Open prices server

I cannot picture exactly how much it will prevent the overload of proofs.
I mean, for the moment in Smoothie we add only prices at the individual product level, but it's temporary. We'll soon be able to add the prices of a whole receipt in one shot (and with only one proof).

I suggest that in "Prices" they recognize identical proof images and return the "old" proof id if relevant - without storing the new one.

we should allow to pick a price proof from your online proof gallery, very much like we already do for regular images

Nice feature, though.

Possible incoherence in the "prices" data model: there are no date or location for proofs:

  • that would be helpful for proof search or proof gallery order
  • possible discrepancies, with prices sharing the same proof but with different dates and/or locations
  • Because currently I am re-adding a slightly different photo of the same receipt for each price using the app 😅
  • This will be largely mitigated by full receipt addition, but depending on user journeys (interrupted or partial input of the products on a receipt, people starting receipt addition from the product page with a single price), we might still want server selection.
  • you are right that there are potential data quality challenges with the uncoupling

I still believe it's a minor issue for very specific rare use cases. And you would need the user to be aware enough of the space needed on the server and to check the proof image repository instead of just taking a new picture.

Would probably be better to systematically ask the user for camera / gallery and also latest local proof / server proofs.
First step is to split the "proof image" button in "camera" and "gallery". Then "server proof gallery". And probably "latest local proof".

Btw, surprised it got the "top issue" label...

@raphael0202 @raphodn Are there some plans about getting smaller versions of proof images, like max width or height = 400?
We don't need big pictures for a gallery.

We already compress the images (done by the web app), so the images shouldn't be that big in size

We already compress the images (done by the web app), so the images shouldn't be that big in size

Thanks for your answer!
You mean size in memory, not in width/height, right? (that wouldn't change much in this particular case, though)
For the record we don't compress images from Smoothie.

@raphael0202 @raphodn Are there some plans about getting smaller versions of proof images, like max width or height = 400?
We don't need big pictures for a gallery.

Not yet, but it's something we can implement. And to answer your latest question, yes we only compress it server-side with webp, we don't resize it.

@raphael0202 In OFF there are 100, 200 and 400 versions (max width and max height).
I think we only use 400 and full versions in Smoothie.
I guess resizing as 400 (on demand only, no need to store on the Prices server?) would be enough for us.

I created an issue on Open Prices for this: openfoodfacts/open-prices#340