reloaded at https://drive.google.com/open?id=0B2q9OrgyDEfPOEZmVlBzLWlnSWc
warning : very far behind dev branch and not maintained
2 Likes
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?
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: Pentax Pixel Shift: Added per channel brightness equalization by heckflosse ¡ Pull Request #3817 ¡ Beep6581/RawTherapee ¡ GitHub
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 
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.