1. What is the issue? Please be detailed.
Collect 2026.3.0 on Samsung Galaxy Tab S8+
When I want to preload a reference image for annotation I have a select with the relevant images. On select, the image question has a triggered calculate with the full path to the image. Previously this could be seen inline (huge).
Before the calculation is triggered, Take Picture & Choose Image are active, Markup Image is greyed out.
After making a selection, Markup Image is enabled while Take Picture and Choose Image are greyed out and the image cannot be replaced (changing the selection will update the default) - This is almost what I suggested a while ago, being able to use an appearance to prevent not using a reference image. Is this intentional? I like the change, but it's not quite executed how I'd prefer it
The selected image is not displayed as a thumbnail under the Markup Image button though.
It's not until it has been annotated and saved that the thumb appears. And this also re-enables Take Picture and Choose Image.
Finally, not an expected behaviour, selecting a reference image, then unselecting it, then attempting to use Markup Image will spinny wheel forever, then tapping back will crash the app. (This is probably as the newly triggered calculation (concat('jr://images/',${filename}))result is jr://images/)
Hi @ahblake
Thanks for testing and sharing your findings!
Yes. We decided that it doesn't make sense to display default images in questions because that's how actual answers are displayed. However, default images aren't saved as answers until you actually open the drawing screen and save it. The previous behavior was therefore confusing.
That's also an intentional change. It's related to what I mentioned above - we decided that it doesn't make sense to display default images in questions. However, if they aren't displayed, users might try to tap the Take Picture or Choose Image button and unintentionally replace the default image, which could be unexpected.
Because the selected image is still the default one, not an actual answer - see above.
Yeah, we considered keeping those buttons disabled. However, once an actual answer is saved, there's no easy way to tell whether it was originally based on a default image or not. Is that a problem for you?
Are you able to provide a sample form? If not, I can create one myself, but it would save me some time.
Thanks for all the explanation. In general i think the changes are good, just getting used to the difference. And i really like that the default can't be replaced with an accidental "take picture"
If it was clearer that a default has been loaded it might cause a little less confusion, the disabled take/choose buttons do hint at this (and users will learn), and I don't have any great suggestions.
It's only a problem if the user forgets they were doing a default markup and snaps a photo! (It happens...) i think it will be less of a problem with the new behaviour (and they still have the option to take/choose without selecting a default if they have an external source to use to annotate.)
Form attached, images are zipped (screenshots from GIS, with text added to identify image from big-image files.)
There are 3x image questions,
can result in a value of jr://images/ for deselect or selects with no associated filename - crash
checks for a nonblank filename before calculating path, otherwise null - no crash (it did crash once on annotate though, but I can't replicate)
instance lookup on image field - crash (related to something @LN explained previously)
WebForms related @JenniferQ : the triggered calculations in the image questions do not return any value (the note with values is blank after a selection). Contrary to my other post in the WF thread, in this one all thumbs that exist display even when image and big-image files are the same (skippy), not sure why this is different to my other form (other one had a filtered select / some big-image files were PDF...) edit: For some reason, now my draft of this form is showing a broken link for skippy, similar to the other issue.
Known, and not a serious issue - If you load a default and don't annotate it (why you would do this I'm not sure) it will validate and upload and even though Central shows a file uploaded (file was submitted click to download) for the question, there is nothing at the path (and the CSV shows attachmentspresent != attachmentsreceived) .../submissions/uuid.../attachments/jr://images/filename.jpg {"message":"Could not find the resource you were looking for.","code":404.1}
To avoid this I enforce annotation with a constraint that doesn't allow jr://images/ in the field.
Not sure what's happening, seems the original files are some how not accessible and reuploading identical files doesn't replace the file (matching hash?) All 3x original image files are broken now:
Then I reuploaded one of the new files with the exact same file - it still appeared, I modified that file (ʍǝu) and uploaded - it still appeared. I uploaded a modified file to devil and that appeared:
The big-image feature is still not supported and results in strange behavior, such as displaying itext with big-image in labels and causing conflicts when saving or rendering those images. I don't recommend using big-image in Web Forms yet.
However, question types with regular images should work.
I tried the form you provided (default-image-crash.xlsx), the calculations don't work (I also got an error in Collect), but it does display the first three images.
I also tried reuploading the images, and they don't break in my version of Central. I'm wondering if the behaviors you described in your last post happened after uploading a new form version and editing a submission from a previous form version. We recently fixed a bug related to that, and it will be released soon (after wrapping up a couple of other fixes).
I might be missing some steps when trying to reproduce these issues. Which version of Central are you using?
I just wanted to say that I've filed an issue: https://github.com/getodk/collect/issues/7322
It's not a priority at the moment, as it's partly a form design issue (the second case is the correct one), but we will address it at some point to avoid crashes.
