I have a script to shrink pictures that stopped working under 10.15.

Scripting Forums AppleScript | Mac OS X
#81

Morning Yvan.

I tested the 3 scripts. 678 and 800 and 1200. All 3 turn the icon picture 90 degrees when finished. However, the original pic is 3.6MB, and the scripts shrink it to 2.5MB and 2.6MB and 3MB respectively.

If I change this line:


			scale openedFile to size 800 --<<<< here we define the wanted greater dimension

to


			scale openedFile to size 80 --<<<< here we define the wanted greater dimension

I get a 1MB size pic but it is now so small it is hard to see.

The one in Post 55 also works, as reported before, here too it turns the icon and the 3.6MB pic is turned in to 3.5 and 3.1 and 2.6 MB size. And I get the dialog boxes.

See my original script kept the picture in a workable/viewable format but shrunk its storage size. Which is what I am after.

#82

There is definitely a problem with your machine (or with you).

When, as you did, I drag and drop your original file :1,754,025 bytes – 3264 x 1836 pixels, 72 DPIs
on a droplet containing the instruction: scale openedFile to size 80

I get logically a small file : 4,826 bytes – 80 x 45 pixels, 72 DPIs

It’s normal that it’s a small one because the edited script asked it to return a file whose greater dimension is 80 bytes what is really done.
An other detail puzzle me: I saved two versions of the droplet.
One of them contains : save openedFile without icon
The other one contains : save openedFile with icon

The created file is the same in both cases and it has no icon.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) mercredi 27 mai 2020 10:59:03

#83

I will reinstall the OS software in the next days to eliminate that one.

#84

I received a new set of files.

The original file is :
4000 x 6000 pixels, 72 DPIs,
file size reported by Preview: 3,203,298 bytes,
file size reported by Finder: 3,203,298 bytes,
no resource fork.

your treated file:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 745,102 bytes
resource fork : $B54A7 bytes (the icons data)

my treated file:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 2535 bytes
no resource fork.

With these infos, things become more clear.
(1) When the inspector of Preview display a “file size”, it’s the size of the data fork component, not the size of the complete file.
(2) The data fork is the same in your treated file and in mine.
So, now, I know that the Image Events resizing task is correctly achieved on both machines.

It would be fine to know what is the size reported by the Finder if you apply this edited version:

on open draggeditems
	tell application "Image Events" to launch
	repeat with currentFile in draggeditems
		tell application "Image Events"
			set openedFile to open file (currentFile as string)
			scale openedFile to size 80 --<<<< here we define the wanted greater dimension
			save openedFile -- with icon -- <<<< don't ask for an icon
			close openedFile
		end tell
	end repeat
end open

In theory you would get:
53 x 80pixels, 72 DPIs,
file size reported by Preview : 2535 bytes
file size reported by Finder : 2535 bytes
no resource fork.

Now, the question is : why am’I not getting the resource fork describing the icons on my side ?
I will try to find what explain this behavior.
Maybe it’s due to the fact that, on my machine, the Finder is set to display icons built on the fly according to the data fork content.
In the pane allowing us to rule the display of windows, the lower checkbox entitled :
“Show icon preview” is checked.
I will search if there is, somewhere, a preference preventing the system to create the resource fork supposed to store the icon.

At least, I’m reassured, the script actually works properly.

Of course, if somebody has an idea explaining why it doesn’t create the resource fork on my machine, I’m all ears.

I’m a little bored to discover that the “surprising” behavior was not on your machine but on mine.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 28 mai 2020 11:09:26

#85

Yvan greetings.

I am presently not at the machine where I have been testing, but will as soon test the new script and report back, as soon as I have access.

You are a kind of detective eh? Wow, what you all discovered. What you say makes sense and is interesting to see how both OS’ behave differently. I now also understand why it is when I pack a pic in an email that all of a sudden Outlook reports a different size. And I am happy to hear you found it and it was not part of my stupidity.

PS for those of you reading this, Yvan and I are exchanging files via private email. This is one of such files he refers to here.

#86

Late news:

under 10.9.5, the icon is created
my old 10.10 HD no longer boot
my old 10.11 HD no longer boot
under 10.12.6, the icon is not created
under 10.13.6, the icon is not created
under 10.14, I don’t know
under 10.15.4, the icon is created

As Shane Stanley wrote, maybe Apple made changed upon Image Events or the underlying framework.

Of course, I would be glad to know the behavior under 10.10, 10.11 and 10.14.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) jeudi 28 mai 2020 15:06:40

#87

Yvan finally back at the machine and time.

The 80 makes the pic small and does not turn the icon. 3.6MB becomes 8kb

I changed the script (yes in the proper way) and one 3.6MB pic (oblong) becomes 75KB and a second (horizontal) 3.2MB > 590KB. And the test pic I send you to becomes 74KB.

So, all in all it seems to work.

Do you know why it changes oblong pics to a different size as the horizontal pics? If I turn the oblong to horizontal it also reduces to ±75kb while before to >±500KB.

#88

For the orientation, I have no idea.
I’m not sure if you say that the picture and the icon are rotated or if only the icon is rotated.
Under 10.9.5 which is able to generate the icons your picture “2 copy 2.png” was “horizontal” and remained such (added icon too).
Your picture “david-pennington-T-GjUWPW-oI-unsplash copy 3” which was vertical remained vertical (added icon too).
Here are the entire results

“2 copy 2.png”, no icon in the original.
originalFileSize : 1754025 bytes, origDimensions : 3264 x 1836, origResolution : 72,0, 72,0
required size 80 fileSize with icon : 48425 bytes, without icon: 6033 bytes, dimensions : 80 x 45
required size 678 fileSize with icon : 86534 bytes, without icon: 42655 bytes, dimensions : 678 x 381
required size 800 fileSize with icon : 105051 bytes, without icon: 61205 bytes, dimensions : 800 x 450
required size 1600 fileSize with icon : 296984 bytes, without icon: 253115 bytes, dimensions : 1600 x 900
required size 3200 fileSize with icon : 1096866 bytes, without icon: 1053025 bytes, dimensions : 3200 x 1800

“david-pennington-T-GjUWPW-oI-unsplash copy 3.jpg”, no icon in the original.
originalFileSize : 3203298 bytes, origDimensions : 4000 x 6000, origResolution : 72,0, 72,0
required size 80 fileSize with icon : 51206 bytes, without icon: 2837 bytes, dimensions : 53 x 80
required size 678 fileSize with icon : 110795 bytes, without icon: 61554 bytes, dimensions : 452 x 678
required size 800 fileSize with icon : 129488 bytes, without icon: 80325 bytes, dimensions : 530 x 800
required size 1600 fileSize with icon : 346521 bytes, without icon: 297378 bytes, dimensions : 1066 x 1600
required size 3200 fileSize with icon : 1303670 bytes, without icon: 1254536 bytes, dimensions : 2133 x 3200

I am puzzled by a feature: For the first picture, you may see that the resource fork (the icons) is quite constant 42392 - 43879 bytes.
For the second one the range is very large : 48369 - 846129 bytes.
I have to explanation for that.

What is sure is that, when you which to reduce the file size, the first thing to do is to drop the icon. It’s why on my machine, when files have a resource fork describing the icon, I remove this fork and just urge the Finder to use a preview as icon. It’s a bit slower but it spare a lot of space. It may be a really useful choice on macBook with small SSD.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) vendredi 29 mai 2020 19:29:53

#89

Indeed a bit of a conundrum. however to drop the icon is a good one.

and thanks again for all your caring help it is much appreciated and sorry for the occasional moment of confusion.

#90

Don’t worry.

I’m too lazy to re-boot under 10.9.5 to check but I assume that Image Events behave differently when it create the resource fork of a png file : size quite constant
and when it create it for a jpeg file : size growing with the size of the file itself.
From my point of vue the late behavior is odd.
I’m quite sure that it would be possible to drop the large resource fork from the large file and replace it by the small resource fork borrowed from the smaller file.

Yvan KOENIG running High Sierra 10.13.6 in French (VALLAURIS, France) samedi 30 mai 2020 15:22:43

#91

OK thanks.