We use images a lot in our day‑to‑day work (for documentation and clinical/field review), and we’re running into limitations with image quality in the Android Capture app.
From what I understand, the Android app currently resizes/compresses images to a medium size (around 512×512) to save bandwidth, and there is no configuration in the standard app or Android Settings Web App to choose a higher quality level. Related feature/roadmap issues seem to confirm that this is still not configurable: [App image quality; Roadmap – better image quality].
Given this, I’d really appreciate advice from the community on:
Best practices for implementations that rely heavily on images:
Do you use Android Capture images only for quick field documentation and then upload higher‑quality images later via web Capture/Tracker?
Do you use separate data elements/stages for “field image” vs “high‑res image from desktop”?
Android‑side options:
Has anyone built a custom Android app using the DHIS2 Android SDK and chosen not to resize images (i.e. not using FileResizerHelper), so that higher‑quality images are uploaded as FileResources? [SDK file resources]
Any lessons learned about performance, sync times, or maximum practical file sizes?
Current recommended workaround:
Is the DHIS2 team currently recommending any specific workflow for implementations that need higher‑quality images but still depend heavily on Android in the field?
Our context: we capture many images per day per user, and in some cases we need to zoom in on details that are not clearly visible after compression. Any concrete examples, workflows, or configuration tips would be very helpful.
Thanks in advance for your guidance and for any experiences you can share.
Thank you for your post. It looks like you’ve done an awesome work investigating ideas .
As a workaround, instead of having to create an entire custom app, you could use a web browser app (such as Google Chrome) on your mobile to login and upload the higher-quality images (see this discussion here: How to control quality of uploaded image).
You’re welcome to add your vote/comment in the Jira ticket you shared above (which correctly addresses your question): Jira
Your analysis is correct and I am afraid there is no way to avoid the resize to MEDIUM for images, at least when using the IMAGE value type. The reason behind this limitation was to reduce bandwidth consumption, but I think it makes sense that the implementation decides whether the image should be resized or not. So having a configuration parameter sounds reasonable to me.
In the meanwhile, the only workaround I can think of is using the FILE value type instead of IMAGE. FILEs are not modified before posting them to the server. The main downside of using FILE instead of IMAGE is the user experience: when using IMAGE, the user can click on the data value, go to the camera, take a picture and use it as the image; with FILE, the user has to take the picture in the first place and then go to the data value, go to the gallery and select the photo. Also, the images are not automatically displayed in the form, it is necessary to click on the data value to “download” the file and open it (the same happens in the web app).
Thanks again for the suggestions. I really appreciate you taking the time!
I tested the browser workaround and it works fine when we’re online. The challenge for us is that we’re often offline in clinic, and then we can’t access or download the higher-quality images, so it’s hard to rely on that workflow operationally.
@vgarciabnz I also tried the FILE value type. It solves the compression issue, which is great. But it seems like the file type doesn’t download offline either? So when we’re offline, we can’t open the image, which kind of defeats the purpose in our setting.
Our reality is: busy clinic, lots of images per day, often offline, and sometimes we really need to zoom in on small clinical details. So ideally we need high quality and smooth offline access without adding extra steps for clinicians.
I’ve also followed the Jira ticket thanks for pointing me to it. Really appreciate it.
If anyone has found a workflow that works well in a high-volume, offline setup, I’d love to hear it.
