1. What is the general goal of the feature?
Ensure that DPI is consistent across images collected by Collect and Enketo. This will make it easier to automate data pipelines that end in a PDF or a physical printout. This has no effect on images viewed on screens other than in a PDF.
Currently images that are taken from cameras maintain their DPI settings (often 300+) whereas Collect sets the DPI of images it processes to 72.
2. What are some example use cases for this feature?
Use Word's mailmerge feature to automatically generate PDFs from collected data.
3. What can you contribute to making this feature a reality?
User research, partnering with @Grzesiek2010 to get it implemented.
We need some help figuring out what the most useful action to take is. Here are some options:
Strip all DPI info and let downstream systems decide how to print
Set 300DPI on all media files collected. This seems like a reasonable default because it's the highest density for low-end modern printers and because it is close to the pixel density of high pixel density devices
Use the source media's DPI (meaning it could still be variable and might not meet the stated goal)
Thanks @LN, this is something I've run into in a couple of instances - mail merging docx where a large image can be constrained by a table cell, but high dpi can cause the image to render too small within the cell and collating images into a PDF using powerautomate in sharepoint and the canvas sizes end up all over the place, eg a low dpi ~2000px long image will be hugely bigger than an A4 page.
In a merge situation, the images need to be local, so these can be downloaded and reprocessed to a desired pixel size and dpi. In the sharepoint setup there is no easy way to reprocess the images this way and inserting images into a document vs attaching as a separate page requires that they be a known orientation/aspect or they end up distorted.
That makes sense though it won't be accessible to everyone.
So... what should we do? 300dpi across the board and document that?
Is 300dpi too high for that context? I guess it would depend on the dimensions so maybe our best bet is still to have a documented, consistent setting.
I don't want to create outputs this way, it is a stopgap!
The distortion/orientation thing is a known sharepoint issue that MSFT aren't dealing with, it shouldn't be a relevant factor here.
My counterpoint would be 'is this actually an issue for anyone else?' or is it only my current sharepoint /powerautomate/PDF configuration where it's an issue (A4 canvas pages followed by 30-40" wide canvas images that are ~2000-3000px wide). In which case perhaps the onus is on me to develop a better output render / image import and reprocess rather than waste ODK resources on making a change that doesn't have a greater benefit.
eg wrt effort on images, I think being able to annotate with shapes & text / being able to annotate and not limit output to screen resolution in Collect / being able to upload images in Enketo and not have to be at 500% browser zoom (existing issue filed) to get decent upload resolution are all more useful to more people and certainly more important to me.
It was but only because I had reprocessed the pixel dimensions down to a suitable size for the layout to minimise docx/pdf filesize without realising that Word would then render it at the image dpi, some of which were 72 (tablet capture or annotated) and some were 300 (external camera capture and not annotated)
So for that context (local merge), which shouldn't be a contributing factor, the 72dpi images were fine but the 300dpi ones ended up too small. I fixed that by including a dpi flag in the batch process.
We were looking at this as a possible quick win but it sounds like it's not clear-cut enough what the ideal behavior would be. I also hear you that some of the other adjacent issues are likely to have higher impact. We'll leave things as they are for now. Hopefully if others run into dpi-related issues they'll comment here and a plan of action will emerge.
300dpi across the board and document that?
I don't want to create outputs this way, it is a stopgap!