Support for Pentax pixel shift files #3489


(Gimbal Lock) #121

Version is 4.2.1216


(Gimbal Lock) #122

This was the raw file I used.
https://filebin.net/4ypvbve94a8l7hpn
Perhaps not the best example to demonstrate PS with as there is little to no gain in using PS here. But it is a challenge for any automatic motion correction since it involves a reflection in water. Water that is almost mirror like, but apparently it did move somewhat.

The MC seems to pick up most movements in the water, but still does leave some spots with checker patterns in them.


(Ingo Weyrich) #123

Thanks for information.

These are already fixed in current version.


(Gimbal Lock) #124

I tested the 4.2.1227 version now and yes, the white balance problem was gone.

Here is another PS shot that shouldn’t have any motion in it at all. I noticed a couple of new MC functions “check red blue horizontal and vertical”, which did pick up a lot of checkered patterns in the water reflection, unfortunately the same function also picks up almost all details in this picture which is absolutely still.

https://filebin.net/7ge1ycju0gbpvf8w


(Ingo Weyrich) #125

Thanks a lot for the example files.

Yes, we’re currently testing some things to detect the checkered patterns.


(Ingo Weyrich) #126

I gave your picture a try.

As you can see at the green motion mask most of the rocks are without motion correction. Moving water is detected as motion and artifacts are almost corrected well (though there are still some artifacts visibly when pixel peeping > 1:1)


(Gimbal Lock) #127

Yes it did get a lot better with this version, but there are still some left in the water when pixel peeping (and PS is all about pixel peeping, if you don’t pixel peep there is no need for PS) especially in the right side of the picture.

On the other hand, PS doesn’t do much good in nature shots anyway (imho) since you as the viewer really can’t tell what is right and wrong when it comes to details in nature. Nature is way to chaotic for that.


(Ingo Weyrich) #128

that’s true for almost all cases, exception is avoiding moiré, for that you don’t need to pixel peep :slight_smile:


(Ingo Weyrich) #129

Update: We added some camera model specific default values internally. For that reason we also changed the behaviour of the Nread and e per Iso adjusters. Means, that when using new version with pp3 files from old version you have to reset the values of this adjusters by pressing the reset button of the adjuster. Sorry for trouble, but it’s still work in progress…


(Gimbal Lock) #130

I’ve played some more and this is looking really nice, but if you don’t mind I have a “small” wish/suggestion for improvement (hopefully).

The size of the green blobs can be varied up to 5 pixels as it is now, I would like to be able to increase that blob size quite a lot, up to 20-30 or even bigger.

The reason being that some motion is picked up easily by the algorithms you are now using, but often there is less obvious motion next to it that is not picked up, unless I increase the sensitivity way up to the point that it picks up details that shouldn’t be removed.

Instead I would like to be able to use less sensitivity but a larger portion around the obvious motion is substituted.

Basically be able to get better MC coverage with less sensitivity, so a possibility to get even bigger green blobs would be nice.


(Ingo Weyrich) #131

During test phase everything is possible. I don’t mind to add larger correction areas for testing though each increase of size will increase processing time (fortunately O(n), not O(n^2), though the area size increases O(n^2)). Currently the correction area sizes are hard coded. Means it will take some coding time to make this variable. In fact, if for testing purposes additional area sizes of 7x7, 13x13 and 25x25 would be sufficient, I would prefer that at the moment. Then we will see if they are useful and can make an implementation using intermediate sizes or not. What do you think?


(Gimbal Lock) #132

Sounds good, maybe there are drawbacks that will outdo the benefits. We will see.

But if we look at the water reflection picture as an example, and pretend that the small tower at the top of the forest were something important that we wanted as detailed as possible.

Then one way to work would be to increase the MC sensitivity until it starts to pick up details in the tower, then back off until the tower is unaffected. Then increase blobsize until the whole water reflection is covered. The details in the water reflection isn’t important, however the checker pattern has to be removed.


(Ilias Giarimis) #133

Ofcourse the better would be to use heuristics so that RT will not picup details with strong sensitivity settings … :wink:
We have a long way …


(Ilias Giarimis) #134

@Marek , can you supply us with a full set of Black Frames from your K70 ?.

you will find directions at Support for Pentax pixel shift files #3489


(Ingo Weyrich) #135

I pushed a new version which has separate adjusters for red/blue sensitivity and allows to use a 7x7 region for motion detected in green channels.

@Gimbal I only added a 7x7 green check because for larger than 7x7 regions I have to take care of the image borders which I don’t want to do currently.


(Gimbal Lock) #136

Ok, will try it as soon as there is a build available.


(Ingo Weyrich) #137

@gaaned92 André, can you make a new win64 pixelshift build if your time permits? That would be very welcome :slight_smile:


#138

In a few minutes from now, W64 release and debug builds of pixelshift 4.2.1241 should be in My RT W64 drive

@heckflosse and users : don’t hesitate to ask for new windows builds (32 and 64) as the process is fully automatic.


#139

Dzięki za udostępnienie !
TNX :wink:


(Ingo Weyrich) #140

Because master branch got some bug fixes and enhancements recently and pixelshift branch was behind master branch by some commits, I merged master branch into pixelshift branch. Nothing new about pixelshift algorithms currently. We are still working on it.