Yes … thats it. When all 4 frames are used we take the average brightness, but when motion is detected we use only one of the frames which happens to be brighter or darker. Choose another frame in the pull down list (1-4) and you see holes in different places or no holes if you are lucky.
A low setting for the correction (the 1-5) slider creates a dithered looking effect which is a better transition in some ways.
Would it be possible to save the motion mask for a specific setting? This could then be used as a blur mask in an external application. Motion blur is a “natural” effect of photography and quite acceptable for background stuff.
I can make a checkbox to show only the mask. Then you could just save it. Which background colour?
Black or alpha would be most useful. Such a feature would really be great for all edge cases where an algorithm just can’t go beyond the limitations inherent in pixel shift.
I just pushed to pixelshift branch 
Exporting the mask works great for doing pixel shift without motion correction and then blurring the chequered artifacts away. It looks close enough to motion blur which is fine unless the trees are the main subject.
I just used gaussian which might not be a perfect result for motion blur but it’s a simple and quick solution. This is obviously no good for the speeding van type motion but for foilage and shadows its pretty decent.
I realized that using the mask to blur migh be doable in Rawtherapee rather than exporting and gimping? I’m sure some sophisticated computed motion blur is possible but gaussian seems to do the job.
Great work!
Currently that’s not possible, though it would be doable with some changes to the code. But I’m not sure whether that is a preferred solution. I would prefer (I guess Ilias too) to solve this motion artifacts without user interaction. At least most of them. For the (hopefully few) remaining artifacts, mask blurring is still an option.
I’m currently working on detecting these chequered artifacts by comparing non green values. Seems like that works not so bad, but I just started.
I keep you informed
I just pushed a new version which checks for differences in non green pixels. Here’s a screenshot
Left is old version, right is new version with red/blue check enabled, from moving van:
I may have found the culprit for those halo like artifacts. There was an active lens correction profile, hence why you couldn’t reproduce. The problem disappears when this is disabled.
I’ve compiled with your recent changes and the new setting does combat the artifacts quite effectively!
Ok, good to know. Currently pixelshift bypasses all raw preprocessing steps while amaze (which is used for the motion parts) applies them. As lcp vignetting correction is a raw preprocessing step, I recommend not to use it (and also not to use any of the other raw preprocessing steps) as long as we are working on motion correction. I will enable most (if not all) of the raw preprocessing steps for pixelshift as soon as we have a good solution to avoid motion artifacts (it gets better from day to day I think).
Can you share the lens correction profile at filebin.net? I would like to enable lcp distortion correction for next pixelshift version but don’t have a lcp to test.
As I wrote two posts above, the latest version of pixelshift branch allows to use raw ca-correction. If raw ca-correction is used, all frames will be ca-corrected before pixelshift process. Here’s an example. Left is without, right with ca-correction:
4 Likes
Great to this amazing progress! Will check the CA fix once I find the time to recompile.
Because there’s a lot of work done and reading all the posts above is a waste of time I want to give a status report of the differences between the “master” and “pixelshift” (Pentax multi-frame file support) branches:
- Improvements related to Pentax multi-frame raw files in general:
- You can process each of the frames using the demosaicer of your choice for pixel-shift files and for 3-in-1 raw HDR files.
- Improvements related to Pentax pixel-shift files:
- You can combine the 4 frames of a pixel-shift raw with and without motion correction using the "pixelshift’ demosaic method. I know it’s not a demosaic method but I didn’t find a better place for it in GUI
- You can adjust the motion correction in several ways, though the default settings in adaptive mode are quite good.
- The regions with motion are taken from the AMaZE-demosaiced frame of your choice.
- Adaptive mode considers the ISO you took the shot for detecting regions of motion.
- “Show motion” mode shows the regions with motion in the color the motions are detected in.
- “Show mask only” mode shows the regions with motion in a grey mask which can be saved for further processing.
- Currently supported pre-processing steps (applied to all frames before pixel-shift):
- Raw CA correction.
- Raw white level adjustments.
- LCP vignetting correction.
- Green equilibration.
- Interpolate bad pixels provided by .badpixels file or by dark frames.
- Currently unsupported pre-processing steps
- Auto hot/dead pixel detection (currently the selected frame is used for that).
- Line noise filter works only on the selected frame (I don’t think we need that for Pentax files at all).
- Flat Field correction
- Dark Frame subtraction
- TODO
- GUI currently has too many controls because we are still testing motion correction methods.
- GUI currently has some bad controls (Pixel-shift motion correction is a slider though a combobox would be better).
4 Likes
Thanks for the lens profile 
Seems to work good when using vignetting correction on pixelshift files
I tested a build I found here somewhere and it is looking very promising. (I had some really weird white balance problems though.) But the motion compensation picked up some really faint problems and fixed them, however also missed some of them that where fairly easy to see for the naked eye.
Anyhow, this is already looking very good. Great fun to play with.
Which revision (changeset) did you test?
Please upload the raw sample and point us to the problematic areas …