Forum Replies Created
-
Posts
-
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.
I did not provide the 500 images number because it’s an internal detail of the app’s implementation. It’s also something that may change with time.
Sorry about the bug – I am able to reproduce it and will fix it in the next update. Thanks for reporting it!
Let’s start with your title. You are incorrect. Nitro’s thumbnails are future-proofed.
Nitro doesn’t work with folders inside the level ‘/Users/username/Library/Containers/com.gentlemencoders.nitro/Data/Library/Caches/File System/FullSize-1’ Throwing all thumbnails into one folder is asking for troubles, I’m afraid to witness soon or already witnessing.You are right. You are asking for trouble. Please do not manipulate the Nitro Previews folder. The organization and format is private to the app. Do not make subfolders. The app will make additional folders (e.g., FullSize-2) when needed to optimize file system performance. The same is true for smaller sizes.
If this goes on, I have to ask “what will happen if I reset the image counter of the camera?” I cannot find a system of ignoring and not ignoring an image.The characters after the file name encode unique information about the file, and thus resetting the image counter is fine.
are existing – but why does Nitro refuse to generate thumbnails?I cannot tell based on this description. See if you have thumbnails in the other folders (e.g., Minis). The app avoids creating large previews when they aren’t needed.
Besides, the context menu with the command “Miniaturbilder erstellen” is far too often absent. For what reason I cannot generate new thumbnails in “Edit mode”? In Capture One “Voschaudateien neu erstellen” is possible in all edit modes if there’s a filmstrip visible.Build Thumbnails >IS< available in Edit mode, but not for the image currently being edited (because thumbnails are built as you edit). If you leave edit mode, but are still viewing the filmstrip (so there is a large image visible), you will see the menu item appear. You can also use it in Edit for images that you are NOT editing by right-clicking on them. I'm sorry that you think the app was so poorly engineered that it cannot handle duplicate file names, or resetting of image counters, or that it would dump millions of files into a single folder. If you have found a bug with thumbnailing, please try to create a series of steps and I will try to fix it. That said, I will not go into deep(er) detail about how the app handles thumbnails.
Square thumbnails is a mode that maximizes the photo in the cell, at the cost of metadata. It’s not the default (at least on Macs). I don’t know what you mean by non-sensical. Some people like it. Nobody is making you use it. Your workflow may be different than mine – it may be different from other people. I don’t enforce a workflow on people and I don’t judge them either.
