Apple Photos app corrupts images

> Turns out “delete after import” was a huge mistake.

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?

I also use RAW+JPG. Latter part allows quick sharing without long post-processing, esp. for impatient friends.

If I'm going to share the photo to an album or something, I process the RAWs selectively.

JPG so you can also see the default camera processing which might be work well from time to time. RAW in case it doesn't.

> 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.

Interesting, based on this and other replies, it sounds like Photos App should have an option to select what to import? i.e. RAW or jpg, but not both.

It sounds like Photos App can have issues trying to import both at the same time?

I don't know why this is downvoted.

> 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"

Thanks dad.

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.

I commend you for your patience with this comment section.

Speed. It all comes down to speed.

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.

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.

Is this downvoted because of the last line i.e.

  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.

With SD cards relatively cheap I long thought about, why delete them at all. Just put them into a box after importing the images/when full. So you still have a physical backup.

> Speed. It all comes down to speed.

GP isn't wrong though. Most cameras embed a medium quality full-resolution JPEG along a couple different thumbnails in raw files, so saving raw+normal JPG is kinda pointless, because the raw already contains that jpeg. Raw+jpg is only easier in the sense that many/most non-vendor tools - even viewers - can't properly handle the embedded jpg so it's easier to just duplicate the storage (e.g. 50 MB for the raw + 10-20 MB for the JPG) and take the hit on storage consumption/transfer time.

My Olympus camera only embeds 1MP thumbnails in RAWs, but my iPhone embeds full JPEGs.

It varies by vendor and sometimes even firmware revision.