Difference b/n Collect + Enketo - low image resolution

Support
1

My apologies if this is already covered, I searched for a bunch of related terms and didn't find what I was looking for, nor is it mentioned in the differences doc

1. What is the issue? Please be detailed.
When adding images to a form in Enketo, the resolution depends wholly on the browser zoom state and display panel resolution.

On my a laptop with 1920x1280 panel resolution, with a form that loads default PNGs for annotation, (all PNGs have resolution 2960x2107 to match the largest tablet resolution, all image widgets have `max-pixels=2960'), the PNG returned from Enketo has increased colour depth and image width of:

  • Loaded at 100% - 616px
  • Loaded at 100% and then zoomed to 200% - 1232px but image is just a 1:2 scaled 616px image
  • Loaded at 200% - 1232px
  • Loaded at 300% - 1590px
  • Loaded at 500% - 1635px
    (non linear increases after 200% due to running out of screen to render on)

Testing same on a screen with resolution 3840x1600:
Image width when loaded at different zoom levels (downloaded from unsubmitted form, not form submissions)

  • Loaded at 100% - 616px
  • Loaded at 200% - 1232px
  • Loaded at 250% - 1540px
  • Loaded at 300% - 1848px
  • Loaded at 400% - 2464px
  • Loaded at 500% - 3080px

Of note, all unannotated images downloaded had filename jr___images_SOURCEIMAGENAME-HH_MM_SS.PNG except one at 300%, which downloaded as SOURCEIMAGENAME.PNG, and this image retained the low colour depth, original resolution as uploaded to Central, i.e. it's the original image, I haven't been able to repeat this once off behaviour with the same default image or other images after ~20 tests. Annotated images had filename annotation-SOURCEIMAGENAME-HH_MM_SS.PNG

Non default images uploaded (Click here to upload file (<100mb)) exhibit the same behaviour, eg a 2587px wide JPG at 200% zoom returned a 1232px wide PNG

Impact - Cannot complete a form in web OR edit a submitted form, as any images added/annotated will be extremely low quality, unless an ultrawide display panel is available and the enumerator navigates in the difficult 500% zoom level.

2. What steps can we take to reproduce this issue?
Load a form with an image widget in Enketo, add images at different browser zoom levels and check the resulting image dimensions.

3. What have you tried to fix the issue?
Upload without modifying / upload at different zoom levels

4. Upload any test forms or screenshots below.

2

Thanks for detailing the current behavior. That's not intentional and I've filed an issue at https://github.com/enketo/enketo-express/issues/447. I'll update when we have a sense of what a fix will look like and when it's likely to come.

3

@eyelidlessness has fully re-implemented draw/signature/annotate! You can check it out on https://getodk.org/xlsform/. You won't be able to verify submissions but you should see that resizing the window is much more performant and retains the fully information of the annotation.

In the case of annotations, submitted images respect the size of the original image that was annotated. For signatures and drawings, the size matches the maximum canvas size as determined by the theme.

1 Like
4

Amazing! :clap:t2: @eyelidlessness

I had a quick look and uploaded a large PNG, zoomed to 500%, annotated and downloaded, then reset zoom to 100%, replaced the image with the same PNG, annotated and downloaded, and both look great.

This means some forms that could never have been completed/edited in Enketo now can be, and a slip of the mouse accidentally annotating an image won't destroy it (apart from changing from JPG to PNG)

If Collect was able to do the same (i.e. not limit to screen resolution), and there were text/shape annotation options as well, then image capture/annotation would be just incredible.

3 Likes
5

Thanks for such quick feedback, I’m glad to hear that it’s working as intended!

I did consider addressing this in the same change, but it felt too far out of scope. But having feedback that the format change is an issue certainly helps. PNG as default is nice because it’s lossless, but I can definitely imagine it being an issue for large-ish photos.

6

It's not a giant issue per se, but JPG photos will inflate dramatically in size as PNGs vs line drawings which will be smaller and look better as PNG (and that is a small issue in Collect, where a default PNG drawing ends up as a JPG).

If a JPG remained a JPG and a PNG remained a PNG, that would be the best outcome i think

Is there a rationale for Collect image timestamp filenames vs Enketo annotation-HH_MM_SS filenames?

1 Like
7

The Collect filenames are milliseconds since the Unix epoch, Jan 1 1970. This was selected to balance length and risk of collision across all submissions to a form. Length is an issue because Windows still has a 256 char full path limit. That’s one of the reasons most exports are flat (all submission attachments at the top level rather than in subdirectories by submission id). Another natural option for automatic filenames would be uuids but those are long. Spec proposal: naming media files has more discussion around submission attachment names.

We don’t know what consideration went into the Enketo naming. Collisions across submissions to a form are likely. We’d like to change that default naming scheme but we’re not sure yet whether we’d want to use the Collect approach or design another one that both could follow.

8

Raising this one again. @eyelidlessness

I had cause to edit a submission to correct a value (not an image), and looking at the change after submitting I saw that all the JPG photos were now annotation-9_0_45.png etc.

Apart from converting to PNG, this also reduced their resolution and dropped them from 2488x1866 (off Collect on device) to 1232x924. (I didn't browser zoom while editing because a) I wasn't interacting with the images and thought they'd be untouched & b) I thought the image being resized was resolved - but perhaps it's not 100%?

Also - downloading an image in Central will return a JPG if it's a JPG, but downloading the image from the image widget in Enketo will return a PNG regardless, with the filename changed from milliseconds from epoch to annotation-xx.

9

Hi @ahblake
As I understand the conversion takes place in Central right? Or maybe you mean that after editing a form in ODK Collect photos were converted to pngs?

10

Yes, i was editing a non image field in Central via Enketo and that's what caused the images to be changed.

11

We've unfortunately decided to revert the resolution-related improvements made to the annotation question type. This had two unintended consequences:

We've tried to fix the existing implementation but have so far been unable to do so without causing other regressions. We've decided it's better to go back to the previous behavior to avoid those two bugs for now.

This change will go out in a Central point release within the next two weeks. I wanted to share this out now so anyone relying on annotation of high-resolution images has a chance to adapt.

1 Like
12

@LN I hate to gravedig this topic but discovered recently that in Enketo an image widget with an annotate appearance will convert an uploaded image from JPG to PNG and downsample the image from original resolution well under the max-pixels value, regardless of whether an annotation is done or not.

I understand the limitations of annotation in Enketo, but would expect images not to be converted or downsampled if annotation appearance exists and isn't used.

Tested just then with a form that had three types of image capture

  • image widget, no annotation appearance - JPG is preserved, resolution resized to max-pixels value (in test from 3000 to 1999px)
  • image widget, annotation appearance but not used - JPG converted to PNG, downsized (in test from 3000 to 1232px)
  • image widget, annotation appearance and annotation used - JPG converted to PNG, downsized (in test from 3000 to 1232px)
13

It sounds like you'd like to have users capture an image and sometimes annotate it but sometimes not and just submit it as-is, does that sound right? Currently the moment you select an image from an annotation question, it is drawn in the annotation window and immediately downsampled.

I know this is an area of particularly high bug/missing functionality density so I don't know whether this idea will be helpful. Do you remember whether dynamic defaults with images work in Enketo? If so, one idea would be to capture the image to maybe annotate using an image question type, no appearance. Then you can have a "Do you want to annotate" question which shows or hides an annotation question with default value set from the captured image. That way you always get the original (possibly scaled down by max-pixels) and in the case where an annotation is needed you also get the converted, annotated version.

14

What happened in this case was a submission needed to have some images added post upload. (As editing is still 'next' on the roadmap,) I edited in Central to add these and didn't realise/had forgotten that Enketo would downsample and convert to PNG if the annotation appearance was present.

The fix would be to publish a temporary definition removing annotation (annotate outside Enketo if needed), edit, upload, submit, then revert the change to the definition for future field submissions.

I did try setting the appearance dynamically eg if(${annotateyn}='yes','annotate','') to allow in form switching (eg default to yes for field Collect users, change to no when editing in Central), but Collect defaults to appearance = annotate regardless of selection, while Enketo defaults to appearance = null regardless. While not the intention, this does allow annotation from the field via Collect and prevent annotation in edits via Enketo but is leveraging a difference in behaviour and not a good idea! :man_shrugging:

Dynamic defaults absolutely do not work in Enketo and this means almost all of my forms cannot be initiated in Enketo as the image will never have its default loaded. (Unlike most of my other image related questions, this one was for captured photos and not dynamic defaults!)

Preserving the original and allowing a second annotated copy is a good idea, and for some cases may be desirable (high resolution original, lower resolution annotation), but as above, it wouldn't work in Enketo. It would get around the screen panel resolution limitation in Collect where the annotation can only be as large as it can be displayed on device, so smaller, low resolution devices could return a high quality original as well as a lower quality annotation.

15

6 posts were split to a new topic: Issue with date comparison in Collect