Forum Replies Created
-
Posts
-
Aperture did not have this problem because it maintained its own library format and did not use XMP files (it would only write them out on export). But the world doesn’t need another proprietary library format.
Using “.xmp” for all images will fail when there is an R+J pair. That’s because both R and J can have XMP files, so the there are two XMP files with the same name (the file names collide).
People have asked me to support this anyway, because they “know what they are doing”. I may do that, but also understand that in that case, you will lose data if you shoot R+J.
Adobe avoids this by writing XMP data into the JPEG file, but that modifies originals which is risky by definition.
Re: the levels handles moving backward: there is a bug with Levels that is fixed in the 2024.4 release (which is scheduled for release in early June 2025)
Since you are not using Apple Photos, then all ratings and edits are stored in XMP files. That XMP files have the same name as the original image with a suffix and file extension.
If you move or reorganize the files, you need to also move the XMP files. If you rename the files, you have to rename the XMP file as well.Again, since you are using the file system, it’s important to use folders to organize the photos. If you combine all of the folders into a single giant folder with 110,000 files + XMP files, performance will suffer (in general – file systems are much more efficient when the files are organized into folders).
The app does not yet have the ability to move images between folders. It’s on the list, but I just have not gotten to it yet. Simple moving is easy, but people usually want renaming features and stuff like that.
One other note. You do not need to use iCloud to use Apple Photos. You can just have a Photos library that is not connected to the cloud.
Lightroom writes the star rating directly into the DNG file. Nitro does not write ratings or edits into DNG files (partly due to a concern about the (very low) risk of data corruption). So there are two places for the data to be located.
So, when you edit the file, Nitro makes an XMP file, but (I’m guessing) the rating is not being copied from the DNG to the XMP. I’ll have to look into it further.
Metadata is a complicated topic. The EXIF button in Nitro invokes ExifTool which parses a different (larger) set of metadata from the libraries built into macOS, which is what Nitro uses for general display and also for export.
When exporting, the app creates a new file, so it needs to manually insert metadata for each key that it knows about. The list that Nitro uses is based on what macOS is able to read. If it’s a key that macOS doesn’t know about, then Nitro will not copy it over (because there is no way to do that). On the hand, there may be keys that macOS reads that Nitro doesn’t support, but that would be easy to add.
Please email me separately (at support@gentlemencoders.com) with the keys that you have set (and also a sample file) – I will see if these are ones that Nitro can insert into the exported file.
It’s hard to say without more information. The app will read XMP data stored within an image file if it’s a DNG. XMP data written to RAW files probably won’t be read unless Apple’s metadata parsing code reads them.
If you open the RAW in Apple’s Preview app on the Mac, do you see the ratings?
Nitro uses the location from the photo library (if you are using that vs. the Finder). And it uses Apple’s Mapping library to display the pin. I don’t know Photos would be worse at that, but I’ll take the win 🙂
The reason the app uses its naming format is to handle R+J files – because there are two files, using .XMP for both will not work.
The app could add “I know what I’m doing” setting, but if you have R+J files, the app will destroy information (by overwriting XMP files). While it’s technically possible to have warnings for such a case, the code for saving XMP is very low level and does not the ability to display an alert, wait for you to answer, and then save, so warnings in that case are not something I’m inclined to add (this is exacerbated in cases of batch processing). So, you would _really_ have to know what you are doing….
iCloud Drive support means using Apple’s APIs for detecting files and downloading them as needed. Thumbnails may be available without a full download, but I don’t know yet. However, if a file has been edited on machine A over iCloud Drive, and then you view it on machine B, the thumbnail will be still be the original image’s thumbnail until the app can download the original and apply the edits to make a local thumbnail. The thumbnail *could* be stored in the XMP, but XMP is a terribly inefficient format for large binary data, so I don’t put thumbnails there. External / network devices don’t go through the same system as iCloud Drive, so changes for iCloud Drive would not have any effect on the NAS case.
It’s on the list to do, but that is predicated on Apple having support for JPEG XL export in their libraries. I do not use open source libraries for this because that would require a completely separate code path.
Blacks in Nitro manipulate the Black Point of the image, so it will shift values off of zero. It is a RAW only control.
Shadows and Highlights move those parts of the image with “some smarts” – however, I am looking into adjusting how those work to be more specific to those parts of the tonal range.
Each app has its own algorithms, and they are not published or documented, so each one will have its own feel.
I have made some videos about when to use Blacks (mostly when you have very dark data you want to recover and exposure or shadows doesn’t do what you want).And if you turn off tabs in settings, make sure to close all the tabs, quit the app and then reopen it. Otherwise, it might restore the tabs.
