iPhoto 5.0.4 Released

[feakbeak]

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing.

Sorry to continue the tangent a bit here, but the topic of binary patching interests me. Does Apple (or any OS X software developers) release byte-level patching updates? It can save a ton of bandwidth and for individual applications it might not be that big of a deal but I would think Apple could save a fortune on bandwidth using byte-level patching for their updates issued via Software Update.

I'm a coder from the Windows world and previously did the install work for my company using the Windows Installer engine from Microsoft, which has byte-level patching built-in. We just released a hotfix for an 80 MB application. The file that had to be recompiled was one of the main .EXEs - about 10 MB in size. We were able to generate a patch to update the application that was less than 3 MB.

I completely agree that byte-level patching is less reliable but Windows Installer compensates for this by caching the original install information and if the binary file on the system isn't an exaxt match of the expected binary file to be patched it will request the original installation source and patch that original source file and overwrite the one on the system with the newly patched file. It's pretty cool when it all works as designed. However, Windows Installer is overly complicated in many ways and therefore does not always work well in some practical cases.

 

[autrefois]

The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.

The biggest single file in the iPhoto application package is the executable binary file itself... this is the program that is iPhoto. This is what you see running in a process listing. Its size is around 40MB, and this is also where the seemingly tiny little fix is located.

Now, with these binary files, you can't (in a reasonable fashion) replace little bits and pieces of it. It's more reliable to replace the whole thing. This is why you have a 41MB file waiting for you.

Thank you very much for the explanation, I appreciate it. I suppose given this information, the 41 MB size is not surprising.

Umm, remember they aren't patching bytecode within iPhoto.

From a coder's standpoint, you have a kind of simpleton reasoning here [...]

Flattery will get you nowhere.

You certainly would agree that most updates from Apple include more changes/fixes while taking up less room. I apparently was not the only person unaware of how this worked and/or surprised at the size of the update, so I appreciate the fact that you have cleared things up.

 

[Trowaman]

BAH!

Just when you thought Apple had no excitement in store for us today

I was extremely happy with today's earlier announcements, both of them. I got exactly what I wanted, not more power but more bells and whistles.

 

[iMeowbot]

Sorry to continue the tangent a bit here, but the topic of binary patching interests me. Does Apple (or any OS X software developers) release byte-level patching updates? It can save a ton of bandwidth and for individual applications it might not be that big of a deal but I would think Apple could save a fortune on bandwidth using byte-level patching for their updates issued via Software Update.

I suppose it's the only way to be sure, given that people do insist on doing weird patch things out in the wild. A dual path, either patch or replace after grabbing a hash, would be nice, but perhaps it isn't worth the bother.

 

[DillWaters]

Patch size

It seems likely that this 5.0.4 updater will work on any version from the 5.0 that is on the original iLife DVDs, through 5.0.1, 5.0.2, etc. Therefore it needs to have ALL the changes from the 5.0 version, even though it may only need 1 or 2 files to patch 5.0.3 version.

The only alternative would be to do what Apple do for the System Updates, which is to release a separate Combo updater for earlier versions.

 

[stcanard]

Flattery will get you nowhere.

I have a feeling there is an expectation difference here.

From a programmer's point of view, this is so obvious that asking the question is a head-banging against the wall type thing.

So we tend to give a head-bang response, then later realize that, oops, not everybody understands the intimate workings of a computer anymore than I understand embedded colour profiles...

So sorry about the sarcasm!

 

[~Shard~]

...modem... users...??

I assume he meant dial-up modem users, not cable modem or DSL modem users...

 

[alex_ant]

Umm, remember they aren't patching bytecode within iPhoto.

Why not?

The download would be the entirety of whatever library contains that code, plus the installer code to do the necessary checks and balances.

If that library happens to contain, say, the image editing library, then 41MB is fairly small.

That sounds pretty primitive to me. I wonder if Apple has ever heard of modular software. Picasa must have because the entire install file is 3.2MB. That's a byte-size-to-this-software-rocks ratio more than 40 times higher than iPhotos.

 

[alex_ant]

So we tend to give a head-bang response, then later realize that, oops, not everybody understands the intimate workings of a computer anymore than I understand embedded colour profiles...

they should have to?

 

[stcanard]

I completely agree that byte-level patching is less reliable but Windows Installer compensates for this by caching the original install information and if the binary file on the system isn't an exaxt match of the expected binary file to be patched it will request the original installation source and patch that original source file and overwrite the one on the system with the newly patched file. It's pretty cool when it all works as designed. However, Windows Installer is overly complicated in many ways and therefore does not always work well in some practical cases.

My guess would be two-fold:

1) From the "it-just-works" perspective, Apple doesn't want to risk updates breaking things (I wonder how much this complication adds to the random updating issues that show up in Windows?)

2) For many moons now Apple has been existing in a multi ISA world. Prior to OSX there was a mixture of PPC and 68K code in the system, now of course we have the issue of upcoming x86 code. It wouldn't surprise me that given this, there would be a culture of avoiding byte-patching because there are too many potential issues.

 

[stcanard]

they should have to?

Nope, but its so obvious to me and everyone knows what I'm thinking

 

[Applespider]

I wonder if this will break something new...

5.0 gave us new features but could corrupt iPhoto 4 libraries on import
5.0.1 fixed the import from iPhoto 4 bug but made large libraries unstable
5.0.2 fixed the instability (somewhat) but gave us the colour shift bug
5.0.3 fixed the colour shift bug and gave us the weird crash/duplicate of rotated images when imported
5.0.4 fixed the rotation bug and gave us ?

Weird though how you wait 2 months for an iPhoto update and then 2 come along in a week or so...

 

[alex_ant]

I wonder if this will break something new...

I don't think so. In order for it to do that, something would have to be working properly in the first place. Your list was informative, but you left off what I think are the more important bugs:

5.0 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.1 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.2 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.3 crashed all the time, randomly corrupted your library, was slow as hell, and used up 800MB of RAM with a 20,000-photo library
5.0.4 ? (haven't tried it yet)

 

[recordprod]

After years of lurking my first post

I love iPhoto etc but bought the new version because of the RAW file features only to find my Canon D30 isn't supported

I hope that Apple adds more cameras to the list as soon as possible!

Mike
http://www.recordproduction.com

 

[chibianh]

someone has a thing against iPhoto...

 

[autrefois]

I assume he meant dial-up modem users, not cable modem or DSL modem users...

Yes I did, sorry about that.

If I could go back in time, I would stop myself from posting in this thread since my original post caused so much discussion and really showed my "laymanosity." It's true that on this forum we have a mixture of experts and people who are pretty much clueless when it comes to computers. I guess I'm a lot closer to the latter group than I thought I was...

Back to the subject of the update: I haven't had any problems with 5.0.4 after installing it and quickly checking it out (but then again I wasn't having any problems to begin with).

 

[~Shard~]

Yes I did, sorry about that.

If I could go back in time, I would stop myself from posting in this thread since my original post caused so much discussion and really showed my "laymanosity." It's true that on this forum we have a mixture of experts and people who are pretty much clueless when it comes to computers. I guess I'm a lot closer to the latter group than I thought I was...

No worries at all, I just posted that for clarification - don't be too hard on yourself.

 

[j-a-x]

Wow that was quick, it took iPhoto like 4 months to fix the editing bug where everything turned red. I'm surprised to see another update so soon!

 

[manu chao]

[...]
It is still slow on both my G4 533 1 GB and my girlfriend's iMac G5 2Ghz which SURELY should be fast enough. Hell Photoshop works faster on my machine than iPhoto does on hers. Really think Apple need to work out why this app is so slow, and inaccurate.
[...]

I would not recommend anybody to run any Mac with less than 1GB of Ram, except if they are willing to always quit programs before starting new ones.
Actually, I would not buy a Mac myself with less than 2GB of Ram (and the option to increase this further).

 

[Doctor Q]

I would not recommend anybody to run any Mac with less than 1GB of Ram, except if they are willing to always quit programs before starting new ones.
Actually, I would not buy a Mac myself with less than 2GB of Ram (and the option to increase this further).

I agree that the more RAM you have the better performance can be, but I disagree with the implication that you can't run many applications at once. The overhead of changing from one active application to another may make that action slower when you have large-memory apps and small RAM, and a single large app can be slow if you don't have enough for RAM for its particular needs, but you shouldn't have to quit applications as we did before Mac OS X to let other apps work, or to make them perform better. Let the memory management code in Mac OS X take care of things with memory swapping and run whichever apps you like.

 

[Mathew Burrack]

Not to continue the continued tangent, but...

1) From the "it-just-works" perspective, Apple doesn't want to risk updates breaking things (I wonder how much this complication adds to the random updating issues that show up in Windows?)

2) For many moons now Apple has been existing in a multi ISA world. Prior to OSX there was a mixture of PPC and 68K code in the system, now of course we have the issue of upcoming x86 code. It wouldn't surprise me that given this, there would be a culture of avoiding byte-patching because there are too many potential issues.

There are ways around both issues, though. The installer, from a high-level perspective, doesn't know or care about what the files are that it's installing, just that they're strings of bits to store on the hard drive. From that standpoint, binary-patching x86 code vs PPC vs 68K code wouldn't make a bit (haha) of difference. Also, IIRC, the fat binaries are really packages containing multiple binary files, one set for each platform, so there's no danger of patching a single file meant for multiple architectures anyway. (Don't hold me to that, I'm working off of memory here

As far as reliability, MD3 hashes are pretty darned reliable in this case. I implemented a system at Cyan that would run MD3 hashes before and after for a patch, and if the file to patch didn't match the initial MD3 hash, it would go and download the full version of the file for you. Ditto if, after the patch, the file's MD3 hash didn't match up. Out of literally terrabytes worth of patching that system did over its lifetime, not once did we find a case where the system failed. Plus, you get the added bonus of fixing any files that might have become corrupted previously.

Granted, it's a more complicated system, but not by much. I could easily see it being integrated in to Software Update as a pre-check to determine whether you can download the binary-patch version of the update or the full-blown version. (They already went a step in this direction anyway, so it could be that it's already in the works and just hasn't gotten to prime time yet). The only remaining chance of something going wrong would be that you had a corrupt file that somehow managed to match the original MD3 hash *and* matched the patched MD3 hash after patching. The chances of that happening are, well, practically nil, and if you happen to be the one unlucky one it happens to, well, that's what reinstalling is for

urm

*ahem*

*shoves thread back on track* nothing to see, move along...



--mcn

 

[jkhanson]

Great!

This update seems to have fixed another bug: some photos would not go into "focus."

Usually, I set the slider to show pictures as big as possible, filling up the whole window. Then I use "page up" or "page down" to scan through photos. Seeminly at random, photos would remain slightly pixelated, as if iPhoto would refuse to put them in the right focus to fit my iPhoto window. I would have to go to the next photo and back again and then I could see the photo properly. So far, all photos have been displaying correctly the first time.

 

[pubwvj]

Does anyone else get really excited when their are iPhoto updates?

No. It is a yawn a minute. iFind iPhoto not iNteresting. I have tried it a few times but always found it to be a dog. GraphicConverter and Photoshop are my best friends.

 

[jettredmont]

After years of lurking my first post

I love iPhoto etc but bought the new version because of the RAW file features only to find my Canon D30 isn't supported

I hope that Apple adds more cameras to the list as soon as possible!

Mike
http://www.recordproduction.com

Did you actually try viewing the RAW from your D30 in iPhoto? I know it doesn't list it as supported, and that the D30 was Canon's first DSLR effort (but not their first digital camera overall, nor their first RAW camera), so it's likely that the RAW formats have changed, but seems it wouldn't hurt trying. Certainly, the more recent Canon RAW cameras are supported ...

 

[Gorbag]

I agree that the more RAM you have the better performance can be, but I disagree with the implication that you can't run many applications at once. The overhead of changing from one active application to another may make that action slower when you have large-memory apps and small RAM, and a single large app can be slow if you don't have enough for RAM for its particular needs, but you shouldn't have to quit applications as we did before Mac OS X to let other apps work, or to make them perform better. Let the memory management code in Mac OS X take care of things with memory swapping and run whichever apps you like.

Good point, and, as i said, Photoshop runs perfectly well on both machines. So why cant iPhoto? Not as if it does a fraction of what photoshop does!