Forum Replies Created
-
Posts
-
Standard Raw Development turns off as many of the Apple decoding parameters as I can. You can do it yourself by moving the sliders and also turning off Lens Correction (and I think) gamut mapping.
Michael, please email support@gentlemencoders.com so I can help you. When we get a resolution, one of us can post here.
I would need more information to tell you what’s going on, but there is a bug in macOS / iOS that affect Nitro with masks. Specifically, if you have the same adjustment (e.g. Curves) in the main interface AND you also brush Curves, then the system gets confused and it applies to the whole image.
To troubleshoot this, take a simple JPEG, make no edits and then apply a mask with Curves. Do you see the same problem?
I might be able to dim out the drive or something, but I’m not sure. The way iOS deals with drives is crazy-making for developers.
I have never seen that. If you can figure out what makes it happen, that would be very helpful. If you see it again, tap on the viewer area to see if comes back. Maybe it’s in some full screen La-la land.
I do not see that problem with panning. If I am zoomed in already, then I can move the image by using one finger on the mouse, or two fingers on the trackpad. If you flick (move your finger very quickly) and it hits the edge of the image, then it may jump to the next image, but panning seems to be okay for me.
I understand, but printing is a black hole. Even something “simple” like a contact sheet is full of various landmines with color proofing and the like. I won’t say ‘no’ for sure, but it’s not a high priority.
I see what you mean. Maps scrolls the opposite way from Nitro, but assistive zoom (I can use control + scroll to zoom into the screen), works the way Nitro does. So, there isn’t a hard and fast rule (at least not one Apple follows). I’ll add a preference in the future.
You can send one to the support email address. I recommend scaling it down first so it goes through the mail servers. Nitro reads and writes the dc:subject XMP entry which is the standard place for this. Lightroom has added a place in their own namespace for hierarchical keywords, but that is for true hierarchy (as opposed to the organizational hierarchy that Nitro uses).
Nitro already supports Finder tags when using the file system. However, Apple made changes in Tahoe that I had to deal with.
If you tag an image in Nitro, it writes the tag to the Finder. If you tag in the Finder, the tag appears in Nitro. The tags and colors that Nitro uses are the ones you have set up in the Finder.
The app could write keywords as tags, but that would be a different feature which would not be using the tags you have in the Finder. My point is that the simple case is easy to do, but there are edge cases that get a little strange. For example, if you have a Finder tag called “Portrait” and it’s green. You keyword an image with Portrait. Do you want the green tag in that case, but the other keywords wouldn’t get colors assigned? I’m guessing yes, but I don’t really know.
