QuickBase really needs to build EXIF image orientation awareness into its image handling...
This is more of a wish/rant than a question (unless someone has a super secret way of remedying this that I'm not aware of). For a platform that touts its mobile-friendliness, I find it very lacklu...
When an image is selected, it is previewed to the spot on the form indicated by "Image" and displayed in a <canvas> item indicated by the spot on the form indicated by "Processed". Once the <canvas> loads I automatically flip and rotate the <canvas> and initiate the download of the processed image. Unfortunately I can't upload the processed image at this time because of my file storage quota.
However, to save the processed image all you have to do is call canvas.toBlob() and submit the blob using FormData API.
While the image is in the <canvas> it is possible to resize it, add a watermark or any other processing you desire. You can also extract any EXIF data from the image and slot it into extra fields on the form.
BTW, the girl in the photo is named Zoe and she is famous:
Know Your Meme ~ Disaster Girl
If you need this non-theoretical feature feel free to contact me off-world using the information in my profile:
Seems like you have a small piece of a potential solution there. If I understand you correctly, you are uploading a stock PNG to a file attachment field, manipulating it via transform instructions that are hard-coded into your script (pre-determined rotate & flip), rendering the transformed image to a new PNG file, then automatically initiating a download of the new PNG to the client.
In order to be a working solution to the EXIF problem I�ve detailed in my posts, this would have to be taken further.
After a user uploads a JPG directly from mobile device�s camera app or camera roll, the solution would have to:
Read the image�s EXIF transform data
Rotate image according to EXIF rotate parameter, to correct for portrait, landscape left, upside down (0, 90, 180, or 270 degrees)
Discard EXIF data, rewriting rotated image file with no EXIF
Re-save rotated EXIF-stripped image to original file attachment field
The last step is as a deal-breaker IMO. Having to upload the image to one file attachment field, download the image back to the device, then re-upload it to its final destination attachment field is kludgy at best. Frankly that's a even less sellable solution than the current scenario of QB natively uploading mobile photos to the database that appear to non-mobile users in the wrong orientation. (Which in itself is already unsellable.)
I think you are misunderstanding the workflow. The script "calculates" something called a blob representing the rotated image which can be submitted to QuickBase directly using the FormData API. The only reason I download the blob is because I can't allow the image to be saved to QuickBase as my file quota will be quickly exceeded. So I am just generating "proof" that the modified image can be created. The blob is a full fidelity binary representation of the processed image. The code I am using is the standard and accepted way of manipulating images client-side (ie in your browser).
I think the difficulty in understanding this is due to the fact that historically the only thing you could do with a file (text, image, pdf etc) was upload it to the server unchanged. Today their are capabilities to fully manipulate both text and binary files both for upload, download or to extract information such as EXIF data or even OCR. This would have been unheard of years ago but browsers have greatly advanced and anything an installed application or a server side application can do can largely be done client-side in the browser. This is not an exaggeration.
I was basing my workflow comments off of what you've seemingly already built, not off of what's possible. I think we can all assume this functionality is possible. Having something built, tested, and demo-able is a different story.
