Preparing images for Google Slides (and other Google apps too)

User comes to tech, tech solves problem, world moves on. Yawn.

Some months ago, I helped with a project to help move someone’s large archive of digital photographs and clipart to Google Drive.  That was easy enough in itself – we just installed Google Drive on their Mac and just moved everything from the appropriate folder on their Mac to a suitable place on inside their Google Drive Folder, on a fast (100Mb synchronous) connection, and let time and Google Drive application do their work.  “Job done…”

Problem 1: Images are over 2MB. Okay, so we’ll shrink them…

…Eeeeeexcept they wanted to use the images immediately, as-is, in Google Slides and other Google apps.  The very first image dropped into their new presentation was too big.  It was either over 2MB, or over some arbitary pixel dimensions that the dialog box didn’t tell the user about.  So back the user came to our team asking what the heck was going on…

Looking at the relevant Google Support page for Docs Editors (as at 10th April 2015, and still not fully populated on 9th November 2015), one might think that just recompressing the images so they *just* squeeze under the 2MB size limit would be enough to comply.  And indeed on this info, given the ‘000’s of images affected, I sync’ed a copy of the affected Google Drive account to a spare Mac, installed Imagemagick (along with its numerous dependencies) and wrote us a bash-script.  Looking at the fileset, I noticed that only the JPGs were over 2MB in size, so I found I could simply tweak the script to look for any JPG over 2MB and use Imagemagick’s “convert” tool to resize the file in-place, then delete the old file to save confusion at the user end.  The basis of the conversion was this command:

convert image.jpg -define jpeg:extent=1970kb image.jpg.smaller

Sure, we sacrifice some overall quality due to JPG recompression, and the script needs to take care of some housekeeping along the way.  But having looked at a bunch of test-images side-by-side, we decided the work involved, and the results obtained were more than good enough for the intended use-case, and indeed any quality losses were barely detectable in >9 out of 10 cases even when pixel-peeping on a decent calibrated monitor.  So on we went with the live dataset after many test-cases, thinking the job was done.

So with the results looking good, off I went to tell the user that the file conversions were done, the results looking good and let us know of any problems.  Meanwhile we’ll move onto the next tasks on our creaking lists.

Problem 2: File size alone wasn’t the issue – pixel dimensions mattered too! D’oh!

Then the dreaded email pinged.  Our poor user had tried to insert the first of the newly recompressed images and sure enough, it had failed to load, and again the same generic helpless dialogue box appeared.  Not because it was a bad image itself – It’s a perfectly valid JPG, and looked very nice, despite the high pixel count and our fears over high compression rates and known multiple recompression steps.  These images are intended for end-use after all, not for further editing, and certainly not for anything other than on-screen use at low DPI output at long distance.

I had to confirm the issue for myself, dragging a JPG onto the insert image tool’s “upload from computer” window finally got the Google Slides image tool to tell me that the image was too big, and finally it gave me the actual limits I was supposed to be working to.

Great.  Now I need to go off and resize my images.  Again.

So, off I went to find a new copy of the original images in their original folders (you do still keep backups of what’s on your cloud storage, right?) Then I worked on a new script, that would resize the images to fit inside a 3500×2500 window, preserving aspect ratio, and would again work for GIF, JPG or PNG since those are all supported by Google Docs.  THEN I ran the same recompression script as before on any files that were still too big after downscaling.  Overall the process took much the same amount of time as the first run, but came with the advantage of the end-result overall looking much better up to the limits of the pixel dimensions and the file size.

Summing up

Some time on our end testing the full end-to-end process might have saved both us and the user some time and hassle, for sure, so my own lesson here is that some short-sightedness on our part for the sake of trying to “get back to other things” most certainly bit us all in the bum.  In our defence however, the process would have been *much* easier had the image dimensions, aspect ratio and file size limitations all been given up-front, NOT just at the point of the image throwing up an error, but also on ALL appropriate import screens, and in accompanying documentation we can search from outside the situation the users face. Another couple of lessons both for developers and support folk here! 🙂

Mac OS X Yosemite Quarantine issues and workaround…

Getting bored of having to do stuff like this, both at work and play.

Many useful Mac apps still come in from places on the Internet OTHER THAN the Mac App Store.  This might be news to the boffins at Apple, but there you go.  This can cause problems at a user-level, where we end up with warning messages like these every time we try and start an installed application:

“xxxxxxxxxx” is an application downloaded from the Internet. Are you sure you want to open it?

AAAAAAAARGHH!  OF COURSE I want to open it! I installed it! I even used my Admin rights to move it to my Applications folder, and it’s been there for months, perhaps years! So quit telling me about this every time I open it!

Okay, chill, breathe, take your meds, it’s time to fix this.  Again, Google to the rescue, and I found a lot of people have been having this kind of issue since Lion.  I have to admit I’ve managed to not have it bite me or my pool of users in the bum at all, (except on first-use of the application, which is fine, because that’s all it needs) until Yosemite.  And specifically, Yosemite’s 10.10.2 point-release.  Ugh.

In all cases, people have reported general success by many sledgehammer-to-crack-walnut means, mostly by turning security and quarantine features off.  I prefer not to do that, so I much enjoyed the more fine-grained solution found here.  Not sure how it’ll work as apps get upgraded, but even if it needs redoing at this point, it’s better than being prompted every time I open an app I regularly use!

So, rather than rewording, I’ll quote D. W. Hoard’s words from his article (linked above):

The quarantine flag can be removed from files or applications that are already downloaded, without completely disabling the quarantine mechanism, by using the following command:

xattr -d com.apple.quarantine /PATH/TO/APPLICATION

A slight shortcut is to type everything up to the path (including the trailing space) in a Terminal window, then drag the desired application or file from a Finder window into the Terminal window, which will automatically paste in the full path to the application or file. If you perform this process using an Administrator account, then the quarantine will be permanently removed for all users on the same computer, regardless of the Administrator privilege level of their accounts.

Oh gosh, I had a horrible thought… it reminds me of the dark days of MS Vista… 😮

Burning Data DVD/CD from Mac OS X “Lion” (10.7.x), for use on non-apple devices

Slight alarm bells ringing here.  It’s been a while since I last had to burn optical media for anything other than DVD-video mastering, so it’s not an issue I’m likely to have come across since the early days of Mac OS X “Leopard” (10.5.x).

This afternoon I happily burned a DVD using Apple Finder as usual, and it all went fine, verifying as usual. Since the target is a mixture of users on Windows and Mac OS X, I asked a Windows-using colleague to check the burned DVD worked on her machine.  Epic Fail.  Came up with the usual dialogue box asking how to open the contents, and Explorer showed the disc as having nothing in the root directory.

When I took the disc back and mounted it on the Mac, I checked in Disk Utility and sure enough, the mounted drive is in the native HFS+ format for Macs. Totally useless on PC’s.  I’m sure Mac OS X used to burn Hybrid media suitable for use on either Mac or PC, but this seems to have changed somewhere in the last few years.

Googling the problem online doesn’t bring up obvious answers, so I had to do a little more digging.  One possible solution was found here in the Apple discussion forums, which I’m now trying for myself.

Burn (Freeware utility) for Mac OS, on Sourceforge

Image

So – I’ve told it to create a disk image suitable for PC’s (as shown in the dropdown menu above), and I’ll mount it in the Finder before burning to DVD to see what format the image actually has:

Image

Good sign – the Finder sees ISO 9660 (Joliet).  Now I just need to burn the image to disk, which I’m doing from inside the Burn app rather than asking Disk Utility to burn an ISO.  I’ll test that later.

So while I wait for the disk to burn. I’ll add to these notes that I need to check the disc on a Windows box, to check that the file names remain intact.  For some uses this might not matter, but for the application I have in mind (sending multitrack audio projects to multiple users for training purposes), the file and directory names to remain intact for Reaper (or any other audio sequencer) to find them again without having have the user point it to them.

As I write this I also realise that the burning process, despite being set to run at 8x (the fastest the drive supports) and the data-set and transfer rate remain the same as in Disk Utility, seems to be taking about twice as long as Disk Utility.

The final result:

Image

Also looking promising – let’s test it on a Windows box and see what it looks like!

UPDATE:  Fail. Comes up as blank DVD in Windows.  

Looks like the only option left in the time available is to transfer the content via USB key and burn the disk on Windows.

Anyone else have any better solutions that don’t involve spending money or reverting to the command-line?