Forum Replies Created
-
Posts
-
I understand that it’s important to your workflow. As far as “feature requests”, there are many R+J customers who have been asking for R+J specific features and those are important to _their_ workflows. At the same time, customers who shoot proprietary RAW are completely unaffected by this. All I can say is that I will add them when I can.
Please see the other thread you posted on about this for an explanation of why Nitro does not use “original.xmp” for DNG / TIFF / JPEG.
Adobe in their infinite wisdom did not create a standard for XMP files for non-proprietary image files (JPEG, TIFF, DNG). For those files, Adobe assumes that the XMP data will be written inside the original file. Modifying the original file is a non-starter for many photographers, who want their originals to be pristine and there is also always the chance of data loss when writing to a file. Nitro supports the idea of immutable originals.
Why does Nitro not use “original.xmp” in that case? Because of RAW+JPEG. In that case, there are two original files and both would try to modify the same XMP file, causing a collision / conflict. For example, it would be easy to rate the RAW and flag the JPEG (say to mark it for deletion). But in that case, both images would be rated and flagged with the same value as there is only one standard place to store that metadata.
At some point (hopefully not long, but there are always so many requests for features and improvements), I will offer the ability to write into the original file and also to let people use the “original.xmp” for JPEGs. As mentioned, both of these have some degree of danger. And, it is virtually certain that someone will have data loss either due to some corruption, or because they have R+J and don’t understand that “original.xmp” is completely unsupported for that style of shooting.
The approach I have taken is less compatible with other apps, but is by far the most safe, and data safety is my first and foremost priority.
It’s compatible, but you don’t need to upgrade.
For example, I have not updated any of my main Macs to Tahoe and don’t plan to. I keep a separate machine with Tahoe so I can test things.
I think there is some confusion here (at least I’m confused). We have to separate out XMP (file system) from Photo library (database).
When using the file system, Nitro does read ratings from original images. However, I see that there is a bug where if you then do something to generate a Nitro XMP file, the rating is discarded. So, I will fix that.
When using the Photo library, Nitro does not read ratings from original files. That is mostly because the Photo Library does not provide them to me. The only way for me to read them would be to read the original file. However, with the Photo Library, that could be in iCloud. So, I would have to download every image, just to see if there is a rating in the original file. I don’t want to do that. If people wanted, I could add a feature where you can select images and it will download them and read the metadata. I just don’t want to download every image “just in case” there is a rating, since it’s uncommon.
Do you have crop or perspective on the image? There is a known problem with radial gradients and things that change the size of the image. It’s a surprisingly tricky problem so I have not figured out a good solution yet. In the mean time, you can turn off crop and apply your gradient and then turn it back on.
There are two ideas that I have:
1) I could try to catch this crash and alert people in case they are running OCLP
2) I could try to look for the OCLP app in /Applications (though sandboxing probably prevents me from doing that).I don’t have OCLP and I don’t have a machine that could use it, which hampers these efforts.
Yes; the crash is because of OpenCore Legacy Patcher (OCLP).
OCLP is not supported by Nitro (it’s in the App Store description). That’s because Nitro uses features of Metal that OpenCore does not properly implement. The crash you are seeing is happening because of that incompatibility. Sorry.
I do not know of a 100% reliable way of detecting OCLP; if I find one, I will try putting up an alert.
For other people watching this thread, Marius sent me a crash log. It appears that iOS is stuck trying to trash the item, and because Nitro calls iOS on the user interface thread, eventually iOS kills the app for have a stuck user interface. I have made a note of this issue – I cannot fix the fact that iOS is getting stuck, but I can move the trash operation off the user interface thread to avoid a hang.
The reason you are seeing that is because the RAW converter is not trying to match the JPEG. It is trying to provide a faithful rendition of the scene. Also, camera companies do not provide information about their in-camera settings, so RAW decoders generally don’t have the information necessary to match them. A simple example is to shoot a picture as Monochrome in the camera. The RAW will be in color. Some companies do try to match the JPEG more closely but they also may be getting information from the camera companies, that I do not. If it’s always darker, then you might consider making a camera preset (the user manual discusses how to do that).
Probably nothing. I have received a few reports of time zone issues – cameras often do not put time zones into the file, so setting the time is not straightforward. Photos also has its own notion of time, which can conflict with the time in the file. Please email support@gentlemencoders.com and I can help you directly. I will need a sample file or two, but we need to do that over email not here (and I will send instructions over email as well for what I need).
Hi, sorry to hear you are having this problem. I have not run into it myself. I created an EXFAT partition on an SSD (I did it on the Mac, fwiw). Then, I put some images into the root of the volume and inside a folder in the volume. I added both to Nitro. Then I selected images in each of the root and the folder and then used the trash icon to delete them. Both worked fine and the app continued to run without freezing.
Can you find a crash log or something that I can look at? You can find those in Settings > Privacy > Analytics > Analytics Data and search for the app.
Also, do you have problems deleting files if they reside in a folder on your iPad, rather than the external disk?
Nitro does not support HDR data in JPEG / HEIF images. It’s on the list to do.
As you suspect / experienced with Photomator, it’s a hard problem to solve in general (and it’s not wise to solve it only partially).
Any edit operation in Nitro will not retain the HDR data (though Revert will restore the data).
Star ratings / flag / keywords are fine to use.
