Support for Pentax pixel shift files #3489


#321

reloaded at https://drive.google.com/open?id=0B2q9OrgyDEfPOEZmVlBzLWlnSWc
warning : very far behind dev branch and not maintained


(Dan Beaty) #322

Thanks for reloading this. I could not get the gtk3 version for XP to run, and yet I see several files for XP available. Should I try another one?


(Ingo Weyrich) #323

For XP you need the one from above link with ‘pixelshift’ in filename (5th from left)


#324

You cannot get any gtk3 version run on XP due to lack of “display window manager” function on this windows system.
For these gtk3 builds, XP should be replaced by Vista in the name.


(Dan Beaty) #325

The gtk2 pixel shift version would freeze when opening a PS image. I have upgraded to Win7 for PS function. I wanted also to say that Raw Therapee is a very useful program! Thanks everyone for your efforts.


(Ingo Weyrich) #326

For information: https://github.com/Beep6581/RawTherapee/pull/3817


(Ronald E Chambers) #327

How different are the two methods of balancing. I would think a channel based method is always best and have an option to control its spatial variation. If the variation is limited to be say 5 times the widest or tallest anomaly, I think that would be best.
RONC


(Ingo Weyrich) #328

Hi Ronald,

The old (but still present) non-channel based method calculated brightness differences based on the median of green channel (because that’s that most reliable channel) and (if enabled) applied the correction factor to red, green and blue channel (think about it as a simple brightness detection in green channel)
The new (optional) method calculates brightness differences for each channel based on the median of each channel.

For the example I posted on github the factors are:

blue  brightness factors by median : 1.14893 1.09496 1.03999 1
red   brightness factors by median : 1.12032 1.07768 1.03366 1
green brightness factors by median : 1.14102 1.08832 1.03719 1

In left view of second screenshot on github green brightness factor was used for all channels while in right view for each channel the per channel (red/green/blue) brightness factor were used,


(Ronald E Chambers) #329

Are global or local values. I think you need a slowly variable application to handle all anomalies in PS. That would handle real changes in illumination in space but fix changes between frames. I think that both methods you have are too variable is done pixel by pixel.
See what I’m getting at?
RONC
Ps: Pixel Shift doesn’t have Pentax on it in the list.


(Ingo Weyrich) #330

It’s in the tooltip :wink:


(Ronald E Chambers) #331

Didn’t look there.
RONC


(Ronald E Chambers) #332

Do you have a physical model for what you are trying? Just throwing statistical methods at a bunch of numbers doesn’t give you a meaningful output no matter how nice it looks.
For PS to work properly, color balance must be correct at every pixel location. But then you need to figure why the data doesn’t fit it. Maybe that is what one of the methods is doing but I don’t see it.
Comments from others. Please.
RONC


(Ingo Weyrich) #333

For the special case when the illumination changes between the PS frames, you get artifacts because the frames don’t match.

To reduce this, RT already had the option to equalize the brightness based on the global green channel brightness which was used (optionally) to calculate correction factors for all channels. That already worked quite well but of course didn’t take into account changes of colour temperature. The new (optional) method tries to get a bit closer to this changes in colour temperature of illumination. Of course this can be only an approximation and will not fit to each part of the image because for example the colour difference in the shadows might be different than in parts which are directly illuminated .


(Ronald E Chambers) #334

Ingo,
I have two ideas for this. First is to take the local median and build your scale factors from distance of local values to the medians. To make that spatially better fit, apply a guassian or boxcar filter the median table then compare locals to it. Next is calculate the old method and save. Calculate using median and blend the two sets of weights. That would probably handle most cases. Might have to bias towards the old method.

Let me know what you think.
RONC


(Ronald E Chambers) #335

Another option might be to apply to old method first and follow by the median or vice versa. They are using different measures to attack different problems.

RONC


(Hermann-Josef) #336

Hi,

trying to understand what pixel shift does.

On the Pentax link quoted above it is said, that each pixel is exposed to the three colours of the Bayer matrix. This implies that the Bayer-matrix is not fixed to the detector, which I had always thought would be the case. So the filter matrix is indeed shifted with respect to the detector? Is this, what is happening?

Hermann-Josef


(Ingo Weyrich) #337

No, the matrix is fixed, but the sensor shifts by 1 px between the frames


(Hermann-Josef) #338

So the statement on the Pentax page is wrong, if the matrix is fixed with respect to the sensor.

So is the issue then that a given spot in the image is exposed through each of the R, G and B filters? These are then aligned perfectly to give the evident improvement in the images, if pixel shift is applied. Is this the difference to just taking four consecutive images and align them?

Hermann-Josef


(Mica) #339

Yes, if I take multiple shots on my tripod with my D750, then each pixel (theoretically) gets exposed to the same pixel on the sensor.


(Ingo Weyrich) #340

I wouldn’t say the statement is wrong. It’s just a question of the definition of a pixel. For example the statement:

Each pixel of the finally combined pixel shift frames was exposed to the three colours

is true.