[Nik Bhatt]

It would be lovely indeed. Unfortunately, it’s not a simple matter.

Adobe does not document how their algorithms work, nor do they document what the parameters in XMP stand for. Here is a part of an XMP from Lightroom.

crs:Exposure2012=”-1.61″
crs:Contrast2012=”0″
crs:Texture=”-50″

Apparently, some algorithms changed in 2012. Even Exposure and Contrast. From what to what? What is “Texture” (mathematically)?

Further, Nitro does not have all of the adjustments that LR has – so all of those would have to be created from scratch AND match theirs.

It’s like translating Italian to English. The letters are the same, and the basics of sentences and grammar are similar. But it has to be done without a) a dictionary, b) anyone to talk to c) how to detect idioms.

Not impossible, but impractical without spending essentially an unlimited amount of time. There are apps like Avalanche that make an attempt, but even they only convert a subset of adjustments, and not perfectly.

[Nik Bhatt]

So, the problem turned out to be a known issue. There is a bug in macOS / iOS when an adjustment is present in both a mask and globally. Apple has given me a few ideas for ways to work around the bug, which I have not had a chance to look into, but I will.

[Nik Bhatt]

A new perspective tool is in the works, so stay tuned.

[Nik Bhatt]

Apple’s decoder does not read that information. The other (larger) apps sometimes read that data and get help from the camera manufacturer to process the image.

I am not aware of Photomator doing it since it also uses Apple’s decoder. It’s possible that they read a few fields – can you tell me specifically what they can read?

Karl’s comment about the LUTs is also valuable – I have some Fujifilm simulations in Nitro (they are not official – I made them by hand).

[Nik Bhatt]

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.

[Nik Bhatt]

Michael, please email support@gentlemencoders.com so I can help you. When we get a resolution, one of us can post here.

[Nik Bhatt]

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?

[Nik Bhatt]

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.

[Nik Bhatt]

No. I am just saying that I’m already aware of it.

[Nik Bhatt]

When not masking, the trackpad uses pinch to zoom in, like on an iPhone.

[Nik Bhatt]

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.

[Nik Bhatt]

Yes, it’s a known issue.

[Nik Bhatt]

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.

[Nik Bhatt]

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.

[Nik Bhatt]

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.

[Author]

Posts