Forum Replies Created
-
Posts
-
Nitro supports color labels when using the Finder, yes. You have to give the app permission to read the labels [Apple hides them].
Go to the Image menu and pick Tags.
The app does not (yet) have file moving / renaming features.
Unfortunately, I cannot tell what is wrong based on what you have provided. Please email support@gentlemencoders.com so we can walk through what is happening.
Another customer mentioned the issue with file extensions. There are a few things going on here.
Nitro uses .xmp for all XMP files. If it’s a proprietary RAW (that is, not a DNG), then it writes with just the XMP extension. If it’s a JPEG, DNG, etc., then it uses the underscore.
It does that to ensure there cannot be a conflict between a proprietary RAW and a JPEG with the same base name. This can happen a couple of ways. One is RAW+JPEG. Another is a RAW + an exported JPEG stored in the same directory. Or, the JPEG is first imported and then the RAW from a R+J pair. Also, this makes it simpler for the app to know what file goes with which.
The terminology of “.jpg.xmp” is attempting to follow a convention of “two extensions”, but that is supposed to be used in a particular case – when the storage is “layered”. For example, TAR and GZIP. That is usually done as x.tar.gz because it’s a TAR file that has been gzipped. Once you unzip it, you have x.tar.
But that’s not true for a file named “.jpg.xmp.” The JPEG is not stored inside an XMP container – it’s not a layered model.
I will probably add a preference at some point to let sidecars be named with the double extension, though I don’t think it’s correct. If I do that, I would update the “Migrate Sidecar” feature to adjust the names of existing sidecars in a directory. I’m not inclined to have the app search for both files and try to figure out which one to use though. Having two files containing similar data always leads to problems.
Unfortunately, this is one of the many things that Apple does not permit for App Store apps. When apps add images to the library, they are always imported as managed (that is, copied into the library). And since Photos has such weak file management, there is no way for you as the user to make them referenced files.
If you are doing these actions outside of the crop tool, then the app will choose what portion of the image to use for the 3840×2160, and it is probably the left part of the image.
I suggest this instead.
1. Open the crop tool
2. Set the aspect ratio to 16:9
3. Type the size into the text fields
4. Position the crop box.Or:
1. Open the crop tool
2. Set the aspect ratio.
3. Position the box
4. Export but choose a custom size of 3840 x 2160.Thanks for reporting that. It’s a bug and I’ll make a note to fix it.
One way to get out of this is to hit the escape key. It will take you back to the grid and the keyboard should work again.There are many ways to organize (or not organize). Some people have existing keywords and keywording systems. It is a popular request.
Some people use hierarchy alone and that’s enough.
Most people probably will not use keywords (I don’t) and that’s fine. AI can also work but has obvious limitations.
Yes, it’s very frustrating. Apple does this by not providing public APIs for developers to read and write keywords. Instead there are private APIs that are only usable by Apple. Some developers have figured these out. But if an App Store app tries to use those private APIs, the app will be rejected by Apple.
Unfortunately, Apple prohibits App Store apps from reading or modifying keywords, titles, descriptions, and other user entered metadata. Some apps have made their own keyword systems, but they cannot store the data into the photo library, which means they don’t sync over iCloud, etc.
I plan to add keywords to the Finder-side of things because that doesn’t have that restriction / limitation.
If Apple ever decides to giver App Store apps this ability, then I would add the feature.
By the way, there is a roadmap on the website: https://www.gentlemencoders.com/nitro-roadmap/index.html
The app has to work differently when you are in edit mode vs. not in edit mode. That’s because you have a live editing session vs. stored editing data. The code to copy and paste is different in those cases. I plan to make the menus and buttons (and contextual menus) more consistent with each other to the extent that is possible / practical.
Correct – when editing an image, please use the buttons next to the Reset button at the bottom of the edit pane. They are Copy Adjustments, Paste Adjustments, and Show Original.
I’ll make a note of your suggestions for localization changes.
As far as the pasted edits being lost, I am not able to reproduce this problem. Can you detail it more please?
Thanks for sending the link. It’s a bug. If you enter the crop tool, don’t move the crop and then hit OK, the app discards the crop. If you move the crop slightly, then it will crop it.
The reason it does not is because move to trash is undoable, but the action of moving to the trash is done outside of the app’s process. That said, the app could do some extra bookkeeping to handle the previews. I’ll put it on the list.
