Forum Replies Created
-
Posts
-
Unfortunately, Apple’s list includes all cameras they support, regardless of decoder version. They do not break out v9 separately and the v9 list remains quite small. I have a page on my own site which lists the v9 supported cameras: V9 Camera List
In addition, DNG files will work with v9, as long as the DNG is not linearized. ProRAW files are linearized, so they are not eligible for RAW v9.
No, that is a different thing. Are you using the purple and green fringe sliders? Those are designed to remove purple and green from high contrast edges but should not be affecting the overall image. of course, if you crank up the range slider, it can affect more of the image. You might try using a mask for the area you want to correct and use the CA sliders on the mask.
Yes, there is a plan to offer more flexible naming of sidecars. The reason that Nitro uses this _jpg.xmp is that Adobe never specified a standard for JPEG / TIFF / DNG for a separate sidecar. They require that the XMP data be written directly into the RAW. Many photographers I have talked to feel strongly that their original images should never be modified, which is in direct conflict with Adobe’s position. The problem with using .xmp for JPEGs is that it will cause data loss when shooting R+J. Both the RAW and JPEG would be sharing a single sidecar, but can have different metadata (e.g., different ratings or flags). Because ratings (for example) are in a standard location, there is no way to have one sidecar represent two independent files. While it is also true that one could “stack” the R+J images as a single entity, people do not always want that, so the solution doesn’t really handle all cases.
Apple’s decoder does not adjust brightness consistently in those cases. It does appear that they look at the DR settings. If you are exposing down, then yes, the image will look darker. Lightroom may be brightening the image to more closely match the JPEG; in general Apple does not attempt to match the JPEG.
Lens Profiles are more complex than they may appear. Some cameras have lens data, but Apple cannot read it (Canon falls into this category – we have found some camera bodies write formats that are mish-mashs of known formats and Apple’s code can’t cope). I have filed bugs about this but no fixes so far.
In addition, sometimes the camera writes data Apple can read, but for a given lens, there isn’t data. This happens more often with telephoto lenses where there is little or no correction for distortion or vignetting.
In the future, I hope to have more lens correction functionality, but it will have to wait until I complete other tasks.
Unfortunately, “flag” is not a part of standard XMP, so Nitro’s reject and Bridge’s reject are not compatible with each other. Ratings are standard, which is why they interchange.
Sorry to hear about that performance. There are variables here, such as speed of the drive and which iPad Air, etc.
Also, the iPad USB connection varies a lot in speed from model to model.
Nitro does cache thumbnails in order to speed up display – so I would not expect it to take 38 seconds each time.
There are two tests I can think of:
1) Copy those images to your iPad – is the app much faster or not?
2) If you make some new folders on your SSD and put 100, 200, 400, 800 images in each folder – how does the performance change vs. the 1200?If you are trying to add images to a Shared Album, then that has to be done in Photos. Apple does not provide an API for third parties to manipulate shared albums.
Another approach is to use the Flag feature of Nitro and then find the flagged album in Photos (it’s inside the Nitro folder). Then share those.
It really depends on the query and the size of the library (and the computer, of course). Some queries are expensive and others are cheap. If you want to provide more information: query, size of library, type of computer then I might be able to tell you if it’s expected performance or not.
yes, but there are other, higher priorities. Like RAW 9 and Liquid Glass, etc. External requirements keep pushing things out. Sorry.
That’s okay – you can fill out the form for beta testing. In there, if you include your App Store email address so I can sign you up for Apple’s TestFlight service, that will save a step. Scroll to the bottom of this page: https://www.gentlemencoders.com/nitro-roadmap/index.html
The list on Apple’s site does not differentiate decoder versions. So, it includes cameras with V7, V8 or V9. You cannot tell if a camera has V9 support from that list.
Ok, I was able to reproduce it all of sudden. Very weird. A fix will be forthcoming. Probably version 2026.09.
Sorry to hear that. As I wrote earlier, the problem is in iOS. The best I can do is to move the trash off the user interface thread so that it doesn’t hang up the app, but it’s still up to iOS to do the work properly. I can also add a delete option.
The 2026.08 update is out, so if you have iOS 27, then you should get a Delete alert in Nitro because the Move to Trash is broken on iOS 27.
Since I cannot reproduce this problem, are you willing to beta test when I have the above changes implemented?
