It would seem that “Crop Image” is compressing the image since I used values that would leave the image uncropped but the new file’s size is smaller.
Also, I can’t open the new image because I think “Write Clipboard to File” is giving me permissions issues.
Hey Keith,
Since you haven’t posted your macro it’s impossible to evaluate your issues.
-Chris
The Crop Image action gives me LZW-compressed image data. So, yes, the image is compressed, but it’s a lossless compression. You won’t lose quality.
If the new file size is smaller than your original image (with the same amount of pixels), then this likely means that your original image was uncompressed (or less efficiently compressed).
‘Write Clipboard to File’ is working fine for me. Maybe change the target folder if you see permission problems?
You can also open images from the clipboard for example in Preview with ⌘N (“New from Clipboard”) or in GraphicConverter with ⌘J.
Thanks for the replies @ccstone and @Tom .
The reduction in quality seems to be from the dpi being cut in half. The files I'm cropping are screenshots from a Retina Macbook Pro at 144 dpi and the resulting images are 72 dpi.
Here is the test macro I created to Crop to original pixels or original points:
Crop Test.kmmacros (8.1 KB)
Writing to file is working now. It must've been from a restart of KM or OS X that fixed it since the original macro is unchanged.
Indeed, it seems the best thing is feeding only 72dpi images to KM.
But it works with other resolutions if you “normalize” them before cropping. See the green actions in the screenshot below.
BTW, in the write action, if you set the output format to PNG and then apply the variable with the original file extension you may end up with pngs with a false extension. (I.e. the format setting of the action will not dynamically change on runtime.)
Crop Test (with ppi correction).kmmacros (10.6 KB)
Perfect, thanks! I wouldn't have thought of that.
In my actual (non-test) macro I was planning on a switch statement that chooses a "write to file" with the appropriate format based on the extension, but thanks for the heads up!
@Tom - Thanks for posting this. I know it was awhile ago, but your green Resize Image action helped me tremendously, with dealing with a Retina display issue.
Thanks!
(By the way, you can use “.x” and “.y” instead of “[1]” and “[2]”, but you probably already knew that.)
Strange. I had thought this issue has been addressed with KM 7.3. See Peter’s comment here, which refers to that observation, which —I guess— is basically the same problem.
By the way, you can use ".x" and ".y" instead of "[1]" and "[2]", but you probably already knew that.
No, I didn’t know that. Thanks!
My issue isn't exactly the same. And yes, I know what Peter changed - I'm not 100% convinced what I'm dealing with isn't a bug he introduced with this change, but since I don't have a Retina display, I can't get "down and dirty" to figure out what's happening. All I know is my problems go away when I use code like you posted. Good enough for me!
No, I didn’t know that. Thanks!
Cool - that's why I posted it - "just in case".