Support for Pentax pixel shift files #3489

I’ve just played with the 1273 build and it’s great. The 3x3new with blur and fill works very well. I’ve have tried a few different files and sometimes the automatic settings nails it, sometimes you have to tinker with the options but in the end the result is very good. Well done!!

In one picture I also got the harsh transition between a single frame and the combined ones, mainly due to me pushing the exposure quite a bit. I figured there isn’t much one can do about that, so looking forward to try the next build.

1 Like

@Gimbal Thanks for your feedback. Very much appreciated! Maybe we can further improve the automatic settings (e.g. make better settings for high ISO files)

@gaaned92 May I again ask for a new Win64 build? :slight_smile:

The changes I made don’t solve this issue completely but at least there is a slight improvement.

I just merged the master branch into the pixelshift branch again. I will do that again when rt5 is released to get a pixelshift version of rt5 (only gtk2 for now)

W64 pixelshift 4.2.1344 builds uploaded (same link)

1 Like

Thank you :slight_smile:

I just pushed to pixelshift branch. I replaced the smooth transitions checkbox with an adjuster.

Example: Left is the output which corresponds to the smooth transitions checkbox being enabled, right is using the new adjuster at its default value.

1 Like

@heckflosse Do you intend to merge master branch now

I will merge it when it’s tagged 5.0 :wink:

Master branch (gtk2 version of RT 5.0) merged into pixelshift branch.

I also created a new branch ‘pixelshift_gtk3’ which is RT 5.0 with pixelshift using gtk3

1 Like

Seeing improvements from the improvements again! Looks good, the blur thing worked well in a couple of tricky soft moving shadow cases.

The 3x3 fill setting defaults seems to be quite agressive. See attached screenshots. The fill “jumps” across and covers a large area. Perhaps it’s the fence provoking it? Anyway tweaking the 3x3 new threshold resolves the issue. In the screenshot below I just switched fill off instead. The filled area is approximately 400x600 pixels so quite large but the mesh is slicing it into smaller tiles.

Oh and I belive I compiled from the pixelshift gtk3 branch just so you know. (doesn’t look very gtk3 though now that I think about it.)

1 Like

Thanks for your test and the feedback :slight_smile:

Exactly. It’s a very simple (and fast) algorithm which has the advantage that its result is predictable by users once I explained how it works. For that reason I try to explain it now:

Assume you pour green paint over the whole image and the detected motion is a barrier for the green paint.
If an area is completely surrounded by motion, the green paint can not flow out. If there is a gap (a single pixel without motion is enough) it can flow out to the next area and so on. If the paint manages to flow to a border pixel of the image which is not a pixel detected as motion, it will flow out of the image.

Btw: May I use your moving van file for a tutorial?

So if you have motion around the edges of a photo the whole file would be amazed? No size limitations on how far the paint will spread? Unlikely scenario of course but interesting.

Feel free to use the photos I*'ve uploaded for whatever purpose you see fit.

Yes, currently if all border pixels are detected as motion the fill algoritm will fill the whole image resulting in a completely amaze demosaiced image. But that’s what the motion mask is for, to let you see what happens instead of being blind :wink:

Great, thank you. That will making a tutorial with good examples much easier :slight_smile:

May I ask for a compiled version of this perhaps?

@gaaned92 Could you make a rt5 pixelshift build or should we wait until the version numbering issue is solved?

Fortunately no :grin: Pixelshift 5.0.75 uploaded ( same link)

This issue broke the automated process I set up, so for the moment building is more laborious and thus less frequent.

2 Likes

Thank you very much again :slight_smile:

The current pixelshift motion detection has some limitations for high ISO files. Today I started to improve that but I only have high ISO files for K-1. It would be great if someone could supply high ISO files (in the range of 1600 to maybe 12800) with motion also from K-3 II and K-70.