I'm using Clip2Imgur to upload images via a shell script. Only trouble is, it fails if an image is over 5mb.
Is there a way to test the size of an image on the clipboard and then resize/compress to bring it down to a reasonable size? Alternatively, is there a better way to upload the clipboard (or finder selection) to Imgur?
Best guess -- clip2Imgur works with PNGs, but Imgur converts PNGs > 5MB to JPEGs.
You could use AppleScript to check clipboard info for when PNGs are > 5MB and then resize them, but it might be easier to see if something else is available to do the job!
It’s a bit lumpy, but I suppose I could temporarily write the file to disk and then get its size using the file attributes action. I feel like there’s a more “route A to goal” method that’s hiding in plain sight…
How are you going to resize? I haven't used KM's built-in action, so don't know how the result compares to something like sips -- especially when doing "odd" amounts like "83% of original". And what you use to resize may determine whether you need a file to work on or can use the clipboard directly.
Meanwhile an AppleScript snippet to get you the size in bytes of a PNG on the clipboard, returning 0 if no PNG is present:
repeat with eachItem in (clipboard info)
if contents of item 1 of eachItem is «class PNGf» then
return contents of item 2 of eachItem
end if
end repeat
return 0
Ok this sorta works but I can't get the resize ratio quite right. At the moment the resultant file size is roughly 1mb, but I can't figure out how to specify an exact size. @Nige_S, you're good at maths, so I'm sure you'll see my error.
In use, if the file is smaller than 4.9mb, the resize is skipped and the macro runs fairly fast; if it's larger, it takes about 6sec, which I assume is mainly AppleScript doing its thing.
Not sure you can. PNG format has lossless compression -- the resulting file size will be dependent on the compression achieved, and percentage compression almost certainly won't be the same as that achieved in the bigger version.
There's also the problem that the size on the clipboard is much greater than the size as a written file -- I don't know which Imgur uses to decide when to JPEG your upload, so we'll play safe and use the bigger, clipboard, value.
If you are trying to reduce every image over 4.9MB to approximately 1MB you'd be looking at
set scaleFactor to SQRT(1/originalImageSize)
set newImageWidth to originalImageWidth * scaleFactor
set newImageHeight to originalImageHeight * scaleFactor
resize image(newImageWidth,newImageHeight)
...if there was no compression.
The nerd in me will also point out that kB -> MB is "divide by 1,048,576" -- 1024 * 1024 -- and not "divide by 1 million"
For me an original 7.9MB on disk and 10.8MB on the clipboard PNG is reduced to 1.5MB by the following -- 150% of what we asked for! That reduces to 1.3MB if you save without the alpha channel. I'm not sure you'll do any better other than by brute-forcing ever-increasing reductions until you reach your desired file size.
Note that if you change the AS to get the TIFF picture size and process based on that, my result was ~800kB w/o an alpha channel, 1.1MB with -- further reinforcing the fact that save options make a difference, PNG compression is throwing things out, and that you're very unlikely to be able to target a file size without some reiteration. IMO, life's to short -- pick a size that you know'll work even when you overshoot, and have at it!
In my own testing, /1000000 gives me the actual file size; /(1024*1024) doesn't.
Yeah, that's how I ended up with 0.67/Local__SizeMB. Seems to get close to 1mb each time, where, as you say, 1/Local__SizeMB was always over by about 50%.
The other issue I've found is that if I open a large (e.g. 23mb) image in Preview, select all and copy, then run this... The macro throws my "ERROR: No image on clipboard" notification. This isn't the case with smaller images.
I'm old. For me, computers still work in binary and I refuse to be hoodwinked by the disk manufacturers' artificial inflation of their drive capacities... Yes, their use of GB as 1,000MB and so on caused some confusion -- and, IMO, they should have been slapped and told to do things properly.
I'll start using MiB when other people stop capitalising the k in kB
More seriously -- what you see depends on where you look. It's "safer" to over-estimate disk usage, transfer times, etc so I use the larger powers-of-2 numbers so I don't get caught out when on a system that does use them.
Perhaps best to rationalise and always use eg files on disk and command line sips if you're often using files that big.