I’ve now tried DT 5.6 from the AppImage with the AI capabilities. Many thanks; the denoise capabilities are excellent. I primarily photograph birds, often using high ISOs, and it’ll be great to have these functions available within DT. My images are almost always cropped, sometimes tightly; I use presets which start my workflow with an area around the center of the frame and proceed from there. In the interests of space (and likely also processing time) it would be useful to me if there were a means to select and pre-crop from the image at the beginning of the pipeline, before or alongside the AI processing, so that my collection doesn’t need to retain and store generated DNGs or TIFFs with sizes over 100MB/processed image, when I know that most of the pixels in those frames aren’t ones I’ll be using. I don’t know if or how such a capability could be feasible to include, or how many users would find it useful, but thought I’d at least flag the idea along with thanking the DT developers for the new features. And/or, I can look for methods to take my Canon CR3 RAW files as input and generate cropped DNGs or TIFFs to input to DT, but that would make for a less convenient workflow.
I hope you don’t take this the wrong way but I’d suggest that this is not really the right approach. If you’re processing large numbers of photos that are tightly cropped at high ISO, it might be better to focus on getting fewer shots where you can get closer, perfecting the technique of optimizing shutter speed, perfecting fieldcraft, or even just perfecting using wider compositions. And it seems unusual to me that you’d be storing the processed images as 100MB TIFFs or DNGs as well.
So, I’d like to suggest that this is not a defined problem that should be solved with automation but that the problem itself is not itself defined quite right. Which is another way of saying that you might solve the problem much more easily by modifying some of the things you do in the field and in-camera, rather than at home on the computer.
Good points, and thanks for considering. I certainly prefer closer, less-cropped compositions in brighter light when possible, but don’t always have that option. Often, e.g., I’m walking with a group, trying to do my best to document sightings for its checklist, and need to make my best of the available conditions with subjects as they’re spotted. When I tested DT 5.6’s Neural Restore with a RAW file representing a 32MP sensor, I observed that the denoise function yielded a 187MB .tif (at least 6 times the size of the input file, or more if its compression was effective); raw denoise’s .dng from the same input file was 65MB by comparison. If I wanted to use the denoise output as a starting point for further DT editing at a later date, I’d presumably need to retain that nearly 200MB .tif in my stored collection or start fresh with a newly-denoised RAW file. Even for a modest number of images, that’s a lot of storage.
Unlike a raw, a tiff could just be cropped and re-saved, couldn’t it?
Yes, that’s an idea; take the large tiff from denoise, crop it, and then use and store the reduced tiff for subsequent edits. More steps than the convenient workflow that’s now present, where the generated tiff immediately appears as part of the collection, but a possible approach.
I think you could do that with Lua scripting where you can connect to an external command to do what you need to do. I have not used dt in a while, but can you not also change the order of modules?
Be careful though. Certain steps still require the whole image frame (besides sensor edges) to process correctly. Also, when you crop early, keep a larger safety zone around your intended region of interest to ensure denoising and other algorithms have sufficient surrounding data to work their magic.
PS If you do not mind and your machine can do full image processing, just follow the regular workflow, extract the JPG and then use something like G’MIC or imagemagick to crop the larger image based on matching algorithms. Again, this may be achievable via Lua.
BTW No AI required in these suggested workflows.
I’d argue that crop is your most important tool I’m any editor. You want to hand that decision off to some algorithm?
The crop may be based on the in-camera cropping done to the raw image, reflected by the JPG. OP may be wanting to preserve that. I have no idea; just a guess…
I’d agree, but it sounds like these are documentation-style photos instead of creative ones, unless misunderstood.
@wevdap Best give us an example file and use case if possible. Thanks!
I’d suggest that no matter what your style or genre, crop is the most major decision, and giving it up seems unoptimal to me. Of course you can disagree 
I don’t understand the suggestion from @wevdap as adding an algo/AI for the cropping decision, but rather be able to crop (like in the cropping module) before saving the tif (resulting from AI raw denoise).
As opposed to do this crop after, on the tif file.
I just tested and if you set raw denoise to zero strength and only use denoise then the crop is applied into a tiff file. If I have any raw denoise in the neural restore then the output is a DNG and crop is ignored. Maybe just try denoise only. Maybe also consider sharing a typical problem image as a playraw so the denoising options can be viewed. I find that the normally non-AI denoising can work well for me when using my Canon R7 at 32000 ISO. But of course cropping or lack of light reaching the sensor can make noise a bigger issue.
I’d argue that if you’re just taking record shots, why not just save the JPEG and throw away the TIFF/Raw file. I mean, are you really going to go back to a Raw file of a record shot? Hey, I take record shots too, but I see zero point in keeping the Raw file afterwards.
@wevdap If I read it correctly, you primary concern is excessive size of the DNG and TIFF files out of AI denoise in neural restore. And you are proposing cropping in the neural restore as a solution.
Let me share my thoughts on what may help in this situation.
First of all, let me explain why the size of output files is larger than you expect. The main reason for this is the fact that output is not compressed. Especially it hearts TIFF which is pretty large.
I think, the correct solution to the problem you described, would be enabling compression for both DNG and TIFF outputs. Another thing, you can already use to reduce size of TIFF output files is bit depth. Current default is 16, you can try 8 to reduce file size if it fits your expectations.
Regarding crop in neural restore module, I don’t think it is a good idea for already quite heavy UX of this module. However, if you apply crop previously in the pipe, neural restore will respect it in denoise and upscale tasks. Raw denoise task works on original file ignoring processing pipe, so will always output uncroped image.
Regarding idea of AI crop in general regardless of neural restore module, my personal opinion is similar to the one @paperdigits shared in the thread. I think crop is one of the most creative dissections we make in our edits and it is very hard to automate it in a right way. From the practical perspective, I don’t see any reasonable open source GPL-3-redistributable models for AI cropping available right now.
IIUC, what the OP is proposing is to have a UI/configuration option to automatically crop around the center of the frame. I.e., use 50% or 75% of the area, either before processing (faster and less disk space) or downstream from that (less disk space).
I wouldn’t use it, but I am sympathetic with the desire of having smaller denoised files. Compression would indeed be a very nice addition.
Compression for TIFF is already proposed in
DNG compression is a bit more challenging though. It will land in a separate PR if I come up with working solution.
Yes, that’s what I had in mind. I’d envisioned using something like the cropping module to reduce the image size, not algorithmic determination of what areas to remove. If that step were applied in constructing the input to Neural Restore’s AI processing, it might (?) also have the effect of speeding up that processing, as the area to be processed would be smaller.
How do you envision this without access to the center view? Crop in the preview widget?
I afraid it would be very inaccurate.
Thanks for the informative insights. Given that raw denoise necessarily must access the original file, I hadn’t thought about the prospect that other modules (i.e., crop) could precede neural restore in the pipe for use by denoise and/or upscale functions. And, yes, output compression would certainly be valuable.