I’m a fan of the whole Apple ecosystem but I have to say that there’s a pattern here. Apple does a decent job of keeping my data safe from others but a terrible job of keeping it intact. From music libraries with song titles that got switched to long integers to this (and I’m sure more that I’m not remembering atm) they need to do a better job here.
Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.
Rare, nondeterministic corruption fits the profile.
I have had extremely bad luck, reporting bugs to Apple.
They constantly ask for an example project, even if it's something that is easily demonstrated, simply by running existing Apple software, and creating a project, would be a huge pain.
They also ignore reports. Very rarely, I may get a ping on one of my reports, asking me to verify that it was fixed in some release. Otherwise, there's no sign that they ever even read it.
I usually end up closing my bug reports and feature requests, after a few months, because I'm tired of looking at them.
It's clear that they consider every bug report to be a burden. That's a very strange stance, but then, they are not a typical company.
I guess you can't argue with the results, as they have a market value North of 3 trillion dollars, but that does not make it any less annoying.
Not to hand wave-- but this feels industry standard IMO. I have a dozen PRs sitting unacknowledged and stale across a handful of FAANG (and other) repos, including Apple's.
I start my first day @ Apple in a few weeks, so I ACK that my opinion might be a little biased here.
Maybe you can help bump FB13400242, a bug that is _literally_ going to kill people. (The bug is that to make an emergency call, even from lock screen, you're supposed to be able to squeeze buttons on either side of the phone. But it only works with the volume buttons on the left - the Action button didn't get supported, when that button was added. So now the rule for teaching a small child isn't just "squeeze both sides" it's "oh but not that one!")
(Yes, this came close to killing someone close to me. Fortunately someone else happened to come along to help.)
Consider hitting up some Apple "watcher" people (e.g. 9to5mac) to see if they can give you a boost on their social media. It's pretty obnoxious that it's come to needing to make a stink like that to get eyeballs on something, but here we are.
> How does one finance a project or a company with increased maintenance costs
You seem to be assuming that the company will eventually pay off the technical debt rather than just continue accumulating it and lowering production quality.
This is what I always do. Rather than go directly from the card reader or camera into Photos or Lightroom, I copy the files onto an SSD, and then bring them in from the SSD. The entire process goes faster.
I also want to point out that I've seen similar corruption in the past, only in Lightroom. The culprit ended up being hardware, not software. Specifically, the card reader's USB cable. I've actually had two of these cables fail on different readers. On the most recent one, I replaced it with a nicer Micro B to USB C cable, and haven't had an issue.
Also interesting that he went from one day's import damaged 30% of his photos, but after replacing everything he had gotten to the point where it took a while to even get a single corrupt photo.
Random is random, and random is clumpy, so maybe swapping parts is irrelevant, but... I wanted more detail on his parts-replacement journey.
He doesn't mention how often the corruption happened whilst he swapped out parts, unfortunately. Presumably it was too rare the entire journey.
edit:
also wth i just realized I went to "tenderlovemaking.com" at work. gross. lol.
I'd be interested in knowing if he was multitasking and using a lot of memory. I know wedding photos are usually something you feel rushed to upload so maybe this issue can be made worse depending on system resource availability.
I wonder if it’s related to import sources, and maybe the speed of that hardware. They are still successfully importing the photos into the Photos app, just not from the camera.
In the late 90s my then-wife was watching over my shoulder one day and saw the domain “freshmeat.net” pop up as a possible auto-completion in my address bar. She was justifiably suspicious until I showed her it was just a software distribution site.
The author's name is tenderlove. He has been a famous contributor to Ruby and Rails for at least 10 years. If this is objectionable to you, it shows your lack of expertise.
It is simply hilarious to make grown adults visit a website called tender love making dot com (a sexual reference) to read a very specific and niche blog about technology.
I also have an OM System camera (OM-5) and never get corruption this bad but occasionally got one row of green pixels at the bottom of a photo during import to Photos. I thought I was crazy, but this motivates me to change up my routine and check if it was Photos all along.
But good gravy that troubleshooting path got expensive real fast. Replacing the laptop and the camera? Why not start by trying something other than Photos? It doesn’t even need to be a paid product; the Olympus software is free not to mention a good baseline since it - of all the applications - should be able to import photos without corrupting them.
Edit to add: delete on import seems pretty risky. My workflow is to import and only delete from the camera after 1) the imported photos are backed up 2) I’ve done a first pass culling.
It would be very helpful to document the version number of the Photos app that demonstrates this behaviour so anyone else who is affected can use this article to keep track of potential fixes.
I hadn’t dug that far in to it, thanks for sharing! I assumed my rather old SD card or the adapter I keep stuffed at the bottom of my bag was the issue as I’ve only seen it on a couple of photos.
I’ve used Olympus cameras for over a decade. Well, the same camera to be honest, a PEN E-PM2. This has only appeared in the past couple of years.
I haven’t seen it on photos from my Canon EOS 80D yet, but I guess it’s time to change my workflow. And maybe OS.
What are some good Open Source / Self Hosted alternatives to Apple Photos (Desktop)?
I pretty much keep my Mac Mini around solely to import photos from our phones, free up space on the phone, and backup the Photos DB. We like to go back and look at old photos from time to time too, and the feature that shows them on a map is a big one for us.
Last time I looked (pre-COVID) there wasn't a lot of promising options, and some didn't support HEIF images
Immich could solve what you are looking for.
It supports wireless upload to the server, everything is stored locally and it has some neat additional features.
I'm fond of digikam https://www.digikam.org/ it's simple enough for most users and has complex features for more advanced users its open source cross platform and doesn't do some weird rearranging of files so you can still use your file browser too.
I shoot RAW but I wouldn't want to eat up all my iCloud space with my RAW files. They're 80MB each off of my Fujifilm camera. I store them on a local DAS instead. Curious what the real use case is for storing RAW on iPhoto.
You can put your apple photos library on an external / network attached drive. Thats what I do, since my photo library has grown to ~300gb. And I'd much rather buy a hard drive than rent one from apple.
There's also the excellent osxphotos utility which can export / backup / migrate photos in and out of apple photos:
I had a weird issue with at least one photo in Apple Photos recently (possibly more that I haven't found) where the photos app showed the image, but I couldn't export it - like it was only a preview. I've upgraded my photos database over many release so I don't know if that's a part of it, the photo in question was from 2018 or so
Somewhat tangental, but I keep my music in the Music app. Wireless music sync is great and usually does what I need. Once in a blue moon, however, it'll absolutely scramble every album cover of every song I have.
Not sure if related but importing images via image capture on mac to the disk of the mac gives you correct time when the photo was taken in the file (kind of important if it’s family photos). But if you import it to a usb drive you get current time as creation time for each file so you’ve lost any timestamp you had on the photos.
> Not sure if related but importing images via image capture on mac to the disk of the mac gives you correct time when the photo was taken in the file (kind of important if it’s family photos).
Something related: exporting originals from Photos used to give the current timestamp back in Ventura, which annoyed me to no end.
They fixed that bug in either Sonoma or Sequoia (I jumped straight from Ventura to Sequoia).
Anything important should be kept inside the file. Filesystem metadata gets lost all the time, isn't consistent between operating systems, zipping up a folder and extracting it will probably mess up timestampts too.
Fortunately it mentions early on in the article that this is related to an Olympus camera so I'm guessing this has something to do with the OM system's flavor of Olympus's proprietary ORF format.
He says the checksums are different but he doesn’t provide a diff to show how different. It could just be a single flipped bit or something. And that could happen in his own RAM/disk/CPU/router so seems premature to immediately blame Apple.
I ran both files through xxd then diffed them. I've literally changed every piece of hardware (at no small cost). "premature to immediately blame Apple" seems a bit off.
I tried running the file segments through a binary diff with Hex Fiend
As far as I can tell:
- 0x7800 bytes were replaced at file offset 0x00aa0000
- 0x2200 bytes were replaced at file offset 0x00aa8000
I can't tell if the replacement data came from a different part of the file, or somewhere totally different. Race condition somewhere sounds plausible.
This is the kind of stuff that makes me wish my Binary Diff Tool was already completed, but unfortunately I'm still working on it. Can't tell much what's wrong with the differences in the bytes without knowing what the structure behind it is.
No, it isn’t. The OP isn’t questioning whether the file changed, but asking what changed to the file, not what changed visibly.
The visible effect shown could be due to a change as small as a single bit flip. It also could be that large parts of the file got overwritten, or that it partially got zeroed. The exact kind of damage can help pinpoint the cause of the problem.
Yeah, I would have been interested in the diff too.
That said, the article does mention replacing basically all the hardware and still encountering the issue. FWIW, my personal experience with Apple software so far is that the usage expected for Average Joe is well tested and polished. But stepping outside of that, it's "Here be dragons" territory very quickly.
I have Apple Photos but I never thought to use it to automatically import my photos and clean it up. My process is very similar to where you've ended up. Thanks for validating it--I'll never change it.
Image Capture did me dirty once. Macbook ran out of space while importing photos but it never stopped and kept on deleting photos from my iPhone. Lost 5K photos of a wedding... submitted a bug and hopefully it has been rectified.
For transferring files (photos or others) from iOS, I have been using Landrop for a while and never had any issues so far, it’s also way faster than using a cable.
I always wonder about the motivation behind these polished, high-quality programs on the App Store which are not open source, and also don't collect (much) data, neither have ads in them.
I used it along with another called Localsend, but the later one gave me a bit of headache and crashed while transferring some large files last time I used it, but still great as an alternative too, and it’s open source as well.
Edit: Actually, you are correct, it seems they did close it! Try localsend instead.
Love LocalSend. Can be a bit finicky but for quick transfers between systems I love it. Use it so my work laptop, Linux gaming PC, and iPhone can easily pass staff around.
Processing RAW can be expensive time wise. If you’re sorting through a session of 10,000 photos, you want the speed that comes with the jpeg variant, which allows you to quickly sort out blurry, smeared, severely mis-exposed, and other various defect photos.
The storage cost is negligible (JPEG75@10MP is cheap) and the workflow benefit is immediate. Additionally, cropping and early white balance corrections (as well as a handful of other things) are much faster to preview with a non-RAW version of the image; since you’ll be processing that detail later anyway from scratch in the RAW later, it’s functionally free to do it on the jpeg version before you dig into the raw.
Additionally, there’s a cheap debugging aspect that you saw here: was it Apple Photos mishandling ORF? Was it something else? When working with both, you have a “reference” that can be used to make sure your digital development pipeline is set up correctly; finer details about the imager can sometimes get mangled by some RAW developers like pixel order and sub pixel blending. Not every CCD is a linear grid, not every LCD looks the same, but if you can get your RAW pipeline producing ≈the same as your camera did, it verifies that you have things mostly set up correctly.
> What's the purpose of RAW+jpg though? Seems rather redundant?
You get to keep out of camera jpg files. Some people might like how their camera processes jpg files and might also want the raw file for a scenario when a more complex editing is needed.
As I said in my blog post, it imports both and combines them in the UI. Also as I said in my blog post, I switched to shooting only in raw, and it still exhibited file corruption.
What's the purpose of RAW+jpg though? Seems rather redundant?
Otherwise, it is wise to highlight that "delete after import" is not a good choice in general.
I personally would not let device A to automatically delete files from device B while files are being copied from B to A.
My workflow is quite manual when bringing pictures in from camera to my MacBook.
- I simply take the SD Card from the camera and then use the SD Card reader on MacBook itself to copy the files (RAW + JPEG) into a working directory.
- Move just the JPEGs into Apple Photos library
- The ones which I think I can/should improve using RAW processing, are processed in DxO Photo Lab and exported to JPEG with a *_DXO.JPEG filename
- DXO Processed JPEGs are added to Apple Photos again. This time due to the naming scheme, the DXO processed JPEGs and camera baked JPEGs are next to each other which helps in quickly checking the results.
- Delete the camera baked JPEG once I am happy with DXO's output
Regarding...
What's the purpose of RAW+jpg though? Seems rather redundant?
...as others have pointed out. Shooting RAW+JPEG is like an insurance policy where if the camera was unable to produce a result which I would like to keep, I have the RAW to play with.
I only keep JPEGs in Apple Photos as all of my image library is backed up to iCloud and don't want that duplication.
RAW files get backed up to another SSD. Looking into a better backup for RAW files.
Also, since I switched recently to a camera which uses CFeB cards for best experience (but also has a SD card slot), the onboard SD Card reader on my MacBook will become useless for this once I get an external CFeB reader.
Because it's utterly irrelevant nitpicking, acting as if a blog post is something that was inflicted on hk1337, followed by a question about a pretty basic concept demonstrating a very limited understanding of the domain, which would be fine if the assumption of good-faith wasn't undermined by the preceding text.
Sure security is important but integrity is too.
Photos does a lot of extra work on import (merging RAW+JPEG pairs, generating previews, database indexing, optional deletion), so my guess is a concurrency bug where a buffer gets reused or a file handle is closed before the copy finishes.
Rare, nondeterministic corruption fits the profile.
They constantly ask for an example project, even if it's something that is easily demonstrated, simply by running existing Apple software, and creating a project, would be a huge pain.
They also ignore reports. Very rarely, I may get a ping on one of my reports, asking me to verify that it was fixed in some release. Otherwise, there's no sign that they ever even read it.
I usually end up closing my bug reports and feature requests, after a few months, because I'm tired of looking at them.
It's clear that they consider every bug report to be a burden. That's a very strange stance, but then, they are not a typical company.
I guess you can't argue with the results, as they have a market value North of 3 trillion dollars, but that does not make it any less annoying.
I start my first day @ Apple in a few weeks, so I ACK that my opinion might be a little biased here.
(Yes, this came close to killing someone close to me. Fortunately someone else happened to come along to help.)
Even if it's standard among tech giants, you could be the one that makes a new standard! Good luck in your new role, btw.
From your description, your experience is quite typical.
This was financed by equally massive technical debt.
That’s what technical debt is. It’s the cost for moving forward quickly. I’m not sure I understand what you’re trying to state.
You seem to be assuming that the company will eventually pay off the technical debt rather than just continue accumulating it and lowering production quality.
Which means that if that bug has been present since the (now unsupported) Mavericks, tough luck!
What's the point of it? It is well known in the industry they ignore bugreports.
Also, this bug doesn't affect the majority of users, so it won't ever be fixed.
I also want to point out that I've seen similar corruption in the past, only in Lightroom. The culprit ended up being hardware, not software. Specifically, the card reader's USB cable. I've actually had two of these cables fail on different readers. On the most recent one, I replaced it with a nicer Micro B to USB C cable, and haven't had an issue.
Random is random, and random is clumpy, so maybe swapping parts is irrelevant, but... I wanted more detail on his parts-replacement journey.
He doesn't mention how often the corruption happened whilst he swapped out parts, unfortunately. Presumably it was too rare the entire journey.
edit:
also wth i just realized I went to "tenderlovemaking.com" at work. gross. lol.
https://gearspace.com/
https://www.reddit.com/r/audioengineering/comments/mftc0g/ge...
C++ reference is one of these.
I don’t even want to know what ZScaler thinks of “tender love making”.
But good gravy that troubleshooting path got expensive real fast. Replacing the laptop and the camera? Why not start by trying something other than Photos? It doesn’t even need to be a paid product; the Olympus software is free not to mention a good baseline since it - of all the applications - should be able to import photos without corrupting them.
Edit to add: delete on import seems pretty risky. My workflow is to import and only delete from the camera after 1) the imported photos are backed up 2) I’ve done a first pass culling.
I’ve used Olympus cameras for over a decade. Well, the same camera to be honest, a PEN E-PM2. This has only appeared in the past couple of years.
I haven’t seen it on photos from my Canon EOS 80D yet, but I guess it’s time to change my workflow. And maybe OS.
Last time I looked (pre-COVID) there wasn't a lot of promising options, and some didn't support HEIF images
https://immich.app/
No longer have to bring laptop or external drive along for backups
There's also the excellent osxphotos utility which can export / backup / migrate photos in and out of apple photos:
https://github.com/RhetTbull/osxphotos
https://www.cgsecurity.org/wiki/photoRec
They finally recognized there is an issue, but there is no fix, as of a few weeks ago :(
I never need to import anything when I can simply copy the data from the card.
Something related: exporting originals from Photos used to give the current timestamp back in Ventura, which annoyed me to no end.
They fixed that bug in either Sonoma or Sequoia (I jumped straight from Ventura to Sequoia).
Anything important should be kept inside the file. Filesystem metadata gets lost all the time, isn't consistent between operating systems, zipping up a folder and extracting it will probably mess up timestampts too.
Personally, I have seen a row of green pixels on the top or bottom + vertically flipped photos on import.
Good sleuthing!
As far as I can tell:
- 0x7800 bytes were replaced at file offset 0x00aa0000
- 0x2200 bytes were replaced at file offset 0x00aa8000
I can't tell if the replacement data came from a different part of the file, or somewhere totally different. Race condition somewhere sounds plausible.
The visible effect shown could be due to a change as small as a single bit flip. It also could be that large parts of the file got overwritten, or that it partially got zeroed. The exact kind of damage can help pinpoint the cause of the problem.
That said, the article does mention replacing basically all the hardware and still encountering the issue. FWIW, my personal experience with Apple software so far is that the usage expected for Average Joe is well tested and polished. But stepping outside of that, it's "Here be dragons" territory very quickly.
Yes this argument is a bit unconvincing for me. Not saying Apple photos doesn't corrupt his files, but this is not real proper investigating either.
https://cdfinder.de/blog/files/image_capture_bug.html
(I'm not sure whether this bug has been fixed or not yet, though I think it has been fixed.)
https://github.com/LANDrop/LANDrop
I used it along with another called Localsend, but the later one gave me a bit of headache and crashed while transferring some large files last time I used it, but still great as an alternative too, and it’s open source as well.
Edit: Actually, you are correct, it seems they did close it! Try localsend instead.
And when your Toyota breaks down, we'll all be there to tell you that you should have bought a military-spec truck.
That's a mistake no mater what application you're importing to, else we'll be graced with another blog post, "Darktable app Corrupts Photos".
What's the purpose of RAW+jpg though? Seems rather redundant?
Processing RAW can be expensive time wise. If you’re sorting through a session of 10,000 photos, you want the speed that comes with the jpeg variant, which allows you to quickly sort out blurry, smeared, severely mis-exposed, and other various defect photos.
The storage cost is negligible (JPEG75@10MP is cheap) and the workflow benefit is immediate. Additionally, cropping and early white balance corrections (as well as a handful of other things) are much faster to preview with a non-RAW version of the image; since you’ll be processing that detail later anyway from scratch in the RAW later, it’s functionally free to do it on the jpeg version before you dig into the raw.
Additionally, there’s a cheap debugging aspect that you saw here: was it Apple Photos mishandling ORF? Was it something else? When working with both, you have a “reference” that can be used to make sure your digital development pipeline is set up correctly; finer details about the imager can sometimes get mangled by some RAW developers like pixel order and sub pixel blending. Not every CCD is a linear grid, not every LCD looks the same, but if you can get your RAW pipeline producing ≈the same as your camera did, it verifies that you have things mostly set up correctly.
Thanks dad.
You get to keep out of camera jpg files. Some people might like how their camera processes jpg files and might also want the raw file for a scenario when a more complex editing is needed.
It sounds like Photos App can have issues trying to import both at the same time?
I personally would not let device A to automatically delete files from device B while files are being copied from B to A.
My workflow is quite manual when bringing pictures in from camera to my MacBook.
- I simply take the SD Card from the camera and then use the SD Card reader on MacBook itself to copy the files (RAW + JPEG) into a working directory.
- Move just the JPEGs into Apple Photos library
- The ones which I think I can/should improve using RAW processing, are processed in DxO Photo Lab and exported to JPEG with a *_DXO.JPEG filename
- DXO Processed JPEGs are added to Apple Photos again. This time due to the naming scheme, the DXO processed JPEGs and camera baked JPEGs are next to each other which helps in quickly checking the results.
- Delete the camera baked JPEG once I am happy with DXO's output
Regarding...
...as others have pointed out. Shooting RAW+JPEG is like an insurance policy where if the camera was unable to produce a result which I would like to keep, I have the RAW to play with.I only keep JPEGs in Apple Photos as all of my image library is backed up to iCloud and don't want that duplication.
RAW files get backed up to another SSD. Looking into a better backup for RAW files.
Also, since I switched recently to a camera which uses CFeB cards for best experience (but also has a SD card slot), the onboard SD Card reader on my MacBook will become useless for this once I get an external CFeB reader.
If I'm going to share the photo to an album or something, I process the RAWs selectively.