Forum Replies Created
-
Posts
-
Setting the dpi value in export only has value in a few situations. Some printers (and printer companies) look at the DPI value when rendering the image. So, I wouldn’t bother setting it unless the printer / print house wants it.
Yes, using file system folders and the Photo Library is a powerful workflow. Quite a few people do that. In fact, Nitro has a specific feature that lets you export originals + ratings + edits between the two systems. So you can edit in a Finder folder and then add the original + all the edits to the Photo Library (or vice-versa) – meaning that you can continue editing non-destructively if you like. Of course, you can also just export a finished image to the Photo Library as well.
Here is the link for people who want to read it. Petapixel Article on RawBridge
No, I don’t see the apps combining. Apps can’t fuse like that – a few parts (that are easily extracted) can be shared, but that’s about it. RawBridge was a large effort and it’s a relatively small part of both apps.
Yes, it’s a good idea to have a more persistent filter (or at least one that is less modal).
When images are added to the file system, the app detects them and updates. No refresh should be needed – what are you seeing and what action are you taking?
Toolbar items cannot be on the left sidebar and “lock sidebar” is too long (especially when localized). I will add tooltips.
There is a roadmap but it’s not comprehensive and it’s not in any order. That’s because some features require research and their timelines are uncertain, and delays with those then affect everything else
LUTs should highlight again. Presets do not. That’s because presets are simply stamping adjustments onto the image. Since you can edit the adjustments afterward, the fact that a preset was applied isn’t 100% accurate. The LUT however, is an uneditable thing, so it is remember (and selected). Are you sure that LUTs are not reselecting (it’s working for me)?
Yes, that’s how the feature works. If you turn on Do Not Hide Sidebar, then choosing a folder or double-clicking an image leaves the sidebar open. However, there is another feature that interacts with it, and it’s somewhat controlled by macOS itself. That is the “Lock” button in the toolbar. If you have the sidebar unlocked then it will hide anyway. So, please check that the sidebar is locked too.
Yes, increasing the depth is planned for the future. I need to optimize this part of the code first and then I can increase the depth. Sorry it’s limited currently.
I think the app telling you these images don’t have embedded thumbnails (which can happen), or they aren’t big enough for a good user experience, with an option to never see the dialog again is a good thing.
Yep.
Grand Central Dispatch is a wonderful thing… when you can use it
I use GCD everywhere, but Apple’s RAW decoder cannot leverage GCD the way you might think. The core problems are GPU utilization and memory consumption which I mentioned earlier. There are always opportunities for improvements, but this is not something that can just be thrown on an async queue and everything gets better.
And I think it is appropriate to say the behavior needs to be different on different platforms
Sometimes. With iCloud syncing and such, the same image will appear on iOS and Mac – if thumbs and previews are drawn differently for the same image on different platforms, then it’s confusing.
And if we differ on that, fair enough
We don’t. However, my workload is zero sum, so I make careful decisions on what to do when.
As far as a thread pool goes, it’s not that simple. Apple’s RAW decoder uses the GPU, so decodes will compete with image loading and editing, and GPUs do not have great tools for scheduling and priority. Decoding also causes memory spikes. On iOS, that will cause iOS to kill the process. These are not simple problems.
Unclear on your question about updating all RAW images without selecting them. No, you have to select them, or use the other setting which will update thumbnails as it goes. In your case, selecting a bunch of images and building thumbnails is likely to work best for you.
As far as prompting people if the thumbnails are low quality, yes, I suppose so. I tend to dislike mysterious-sounding dialogs or having the app behave in different ways based on the image type (e.g., it could see you have crappy thumbnails and then update them) because people won’t understand why some images update and others don’t. And no one reads alerts.
Nitro reads thumbnails and previews from the RAW file. Many camera manufacturers produce substandard thumbnails and previews. For example, Hasselblad is infamous for its tiny preview for gigantic sensors. Sony historically also produces needlessly small embedded thumbnails / preview.
You can see the size of the embedded preview by using Exiftool.
This is what I get for a Sony A7R3 (42 megapixels) – the preview is 1.7 MP. That’s bad!
Full Image Size : 7952×5304
Preview Image Size : 1616×1080Lightroom does not have this problem because it requires that all images be imported. During that process it replaces the thumbnail and preview with its own rendering. But that import process takes time. Nitro avoids import entirely and just reads the files. The downside is that it is reliant on having a decent thumbnail / preview from the camera.
There is a solution to this. You can do one of two things (short of using a camera that produces decent embedded images)
1) Select the images and use Build Thumbnails. That will take some time, but it has to open each image and process it.
2) Go into Nitro Settings and turn OFF “Quick Preview” and also turn ON “Update Thumbnails in Quick Preview”. The app will then replace thumbnails as it goes with the RAW rendering.Of course, you can do both.
These are not the default because rendering thumbnails from the RAW slows the app down.
Jock, my feeling are not easily hurt, so your comments did not bother me greatly. However, I would say that you seem aggravated and that tone did seep into the post. And despite your statement, “I was pointing out a scenario they apparently didn’t consider and haven’t addressed,” I have both considered and (attempted) to address it.
I hope these features in the app help with your workflow.
Hi Jock – sorry to hear you are having these issues. It certainly sounds frustrating. I am unclear on some of your terms. What is a “proxy?” Are you referring to thumbnails in the grid, or larger images in the viewer?
As far as updating, are you referring to decoding of the RAW? and if so, updating how? Do the thumbnails need to be re-rendered for some reason? What’s wrong with them?
What camera(s) are you using? Does this also happen with JPEGs?
