Support for Pentax pixel shift files #3489

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

1 Like

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.

1 Like

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.

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

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

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,

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.

It’s in the tooltip :wink:

Didn’t look there.
RONC

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

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 .

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

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

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

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

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

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.

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.

Good evening,

I do not agree. The pixel is not subject to definition. It is a physical item on the sensor. So the question remains, is a given pixel, i.e. a given piece of silicon, exposed to R, G and B light or always to the same colour.

Hermann-Josef

According to your definition of a pixel ;-), of course it’s only exposed to one colour, because the matrix is fix.