I’ll check this out. The macOS photo library situation is really embarrassing. I actually migrated from Affinity to DxO Photolab (expensive!) a few years ago just for that.
As someone who has had to use Creative Cashcow tools in the past... dare I ask what the hell was Bridge even for? Just an Adobe-developed file manager?
As the OP mentioned, seems inefficient to upload RAWs for processing and culling online. However, extracting and uploading the embedded or sidecar full-res JPEG, editing that non-destructively, then applying the edits to the offline RAW copy seems like it might work better.
I would argue that the choice to render the embedded JPG is optimal from the UX of a Fuji user. We tend to use the JPG as the creative reference we want to start from using the film sims.
Have you compared the image colors on the screen between your implementation and Adobe Bridge? Are they significantly different because of LibRaw, or is it not a problem?
They look different, I display the jpeg preview backed into the raw, Bridge i believe decodes the raw and applies a default processing, they are more contrasty.
12 comments
[ 0.30 ms ] story [ 34.6 ms ] threadI’m building photopipe.app, a paid cloud-based culling tool, so I’m taking the opposite approach. Curious what made local-first important for you.
Has a lot of opportunity on the actual image rendering and performance side, but will definitely keep up with updates on how it evolves!
So I am sure to try this. I’d love to see closer integration with Affinity where that is possible.
Have you compared the image colors on the screen between your implementation and Adobe Bridge? Are they significantly different because of LibRaw, or is it not a problem?
Thanks!