Annabel

All sharpening and blurring modules use the resolution of the pipeline at the stage where they are put. Those modules are highly scale-dependent and trying to account for resizing (for example, setting the pixel size with regard to raw resolution and correcting it for actual resolution when applying the module) will be at best inaccurate. There are 2 reasons for that :pixels are integer numbers, so rescaling a 3 px diameter by 50% leads to either 1 px or 2 px. 1 px is basically equivalent to doing no blurring or sharpening at all, and 2 px is a 17 % error.some internal parameters (like edge-avoidance) have a 2D dependency to the image features in the region used for blurring/sharpening, which can't be reduced to a simple correction factor to apply on user input to account for image scale.That said, we still try to perform these inaccurate corrections in darkroom previews, for the sake of having something to preview. But for robustness of exports, we avoid them in this context. In the same spirit, the option to export with early downscaling (after demosaicing), for the sake of speed, has been removed recently, so the downscaling will always happen within the "final rescaling" module, at the end.Ansel prevents export size from being larger than the input raw size, without option, because it's the safe thing to do. Properly increasing resolution requires "super resolution" algorithms that use machine learning/AI to infer the content to dilate.Now, you need to decide what you want to sharpen, and that's mostly deciding what kind of blur you want to undo. Lens blurs or demosaicing low-pass (aka blur…) are defined optically, in scene-referred space and in sensor coordinates. These need to be undone on scene-linear RGB, using pixel coordinates relative to sensor coordinates, so there is no need to move the modules achieving that past final resolution module.There has been a trend, among digital photographers, to sharpen after downscaling images. I have personally never done that, both because I find oversharpened pictures way more disturbing than slightly soft ones, but also because uploading pictures to web services may resize thumbnails on the server (typically, to support responsive image sizes and please Google), and those services usually don't resharpen thumbnails (except for Flickr - who is still using it in 2025 ?). In that case, the look of your images may be inconsistent depending on viewing scale (which may load a different image file, if using responsive images sizes), so it's better to just do nothing.Now, if you still wanted to sharpen post-downscaling, you should probably do so with a small radius (1 to 2 px, so that's a diameter of 3 to 5 px), and those are pixels relative to the coordinates of the final size, which any module in Ansel will use when placed in the pipeline after the final rescaling.Be aware, though, that sharpening may create negative RGB values in the darkest areas. Filmic has some tricks to recover them as to avoid creating chroma noise, but later modules don't, and anyway, you might end up crushing shadows, depending on image content. All in all, sharpening late in the pipe is more like a ticking bomb.

Ok, so here is how it works:You can see the history of commits there: https://github.com/aurelienpierreeng/ansel/commits/master/The AppImage and Windows build have an uniform naming pattern. For example, for tonight's package, it's Ansel-0.0.0+1028.gecaf9d6f-x86_64.AppImage. 0.0.0+1028 means we are 1028 commits after version tag 0.0.0. Then, gecaf9d6f means "Git ecaf9d6f", where ecaf9d6f is the last commit that was included in the AppImage.Find that commit ID in the commit history:So this is the step at which the package was built. Every commit older than this one will be included in the package.Or… the packages are nightly builds, auto-built everyday around 1am UTC. Meaning anything that got commited the previous day gets included.