Support for Pentax pixel shift files #3489

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.

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?

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.

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 …

@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 - #91 by ilias_giarimis

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.

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

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

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.

3 Likes

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

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.

Pixel shift options in menu RT are not translated into Polish language :frowning:

@Marek you can help with that once the English strings in the pixelshift branch are finalized: Localization - How To Translate RawTherapee and RawPedia

@Marek, pixelshift is far away from being complete. gui changes all days while we are testing. As @Morgan_Hardwood wrote: it does not make sense to translate unfinished stuff :slight_smile:

I do like the function to increase the size of the regions, even though there isn’t much difference between 5x5 and 7x7 the increased size does close up some of the gaps that otherwise are left uncorrected. But even bigger size would be nice if it’s doable.

The red/blue functions do pick up lots of faint checker patterns but also have a habit of picking up the details that you would like to preserve, that is why a lower sensitivity (to the keep the details) and larger blobs to cover the problem areas more effectively is nice, at least when working with the current PS pictures I have right now.

Status report:

We are currently working hard on some new methods to reduce the number of false motion detections while increasing the number of true motion detections. As soon as the the stuff is worth to be pushed to pixelshift branch I will do that…

1 Like

Sounds good. In the mean time I can share yet another pixel shifted image. Nothing extraordinary in any way but it does involve a lot of motions. The car closest to the camera like to leave some artefacts, there is also some on the back of the people to the right in the picture that is hard to remove without removing solid details.

There are some nice details that can be found on the houses in the distance that one like to preserve, for instance look under the black roof for some ornaments on the wall.

link:
https://filebin.net/oji6fsphuvtltfif

Gimbal, thanks for providing a new example file. We really need as many of them as possible.

I had a look at your file using latest (unofficial) development version. The car artifacts are solved and the detail in background is also preserved much better with that version. The artifacts on the back of the people is better but still not good. I will have a look at that now…

Edit: here’s a screen shot of the people artifacts

Hi,
this artifact is removed by enabling nongreenamaze.
Vitalis

Hi Vitalis, it’s not completely removed. But I have to admit, that I lost the overview what’s in official and non official rt pixelshift test versions…