Appion

Hi Gabe, Do you know anything about this. I want to change the binning back to an integer, because I am not sure how to deal with a float. What should the behavior be is the user selected an unbinned box size of 128 and binning of 3, giving a final box size of 42.67 pixels

Introduced in commit:523bcc0c

In the makestack webpage you set the final desired box size if you choose a Relion stack. If I extract at 256 & want a 100x100 final box size, the binning will be set to 2.56
There shouldn't be a way to set a final box size as the a float in the gui, so it's odd that you're getting this error. Maybe we should add code to ensure that the binned box size is an even int value?

So, you are scaling the image not binning it correct. Should we have a different parameter for scaling, since it involves some interpolation.

At a minimum, we need to add a check conflict such that boxsize/bin == int(boxsize/bin)

You're right, it's not binning, Relion scales by windowing in Fourier space. I'm ok with a new parameter for Relion scaling, it doesn't matter to me what we call it. I just figured we could use the binning parameter if we had checks in the code, since this is transparent to most users.

Okay, what do we do? I want to make binning an integer again.

If you want it to be an integer then we need to add a new parameter called scaling.

What is the purpose of scaling? I thought it would be something you want to avoid.

Separating bin from scaling would be the cleanest. Instead of scaling factor, should you just input the original boxsize and the final scaled boxsize.

for initial 2D & 3D we scale everything down to 100 pixels & then unbin for final refinements. If the box size is too large for the GPU workstations, we scale to 1 Å/pixel for the final refinements. Since Relion scales by Fourier windowing it doesn't have to be an integer. I'm fine with setting a final output box size or desired pixel size.

Relion scaling is in Fourier space. It then means cutting off high frequency component which should increase S/N ratio in real space in some form assuming white noise (present at all frequency) and that the signal is well below noise beyond the cutoff. I think the feature is valid and should be there. From what Gabe said, it is used for in practice. I am for it.

I am for it if we do the scaling in Fourier space. I did not want to do any more bilinear scaling.

Scott has been opposed to this in the past. Mainly because cutting the frequencies off like this will produce artifacts, especially when fiducial markers are present. We would need to consider using Hann window filter if doing this.

Sorry for the duplicate message. I am on vacation and just got to a computer instead of my phone. Yes, my feelings on binning vs Fourier scaling are unchanged. I'm OK if we add Fourier scaling as a new option. I think Neil summed it up nicely. I like binning because it increases the signal to noise ratio especially for integrating cameras (as I understand it), and it doesn't have potential for artifacts like Fourier scaling does. I think it's fine if we add it as an option that is not the default, and old binning is still there. It's also worth looking at the results of the reconstruction challenge. I think there may be a trend where data processed with scaling perform worse than those with binning, but that will need a little more analysis.

I guess my next problem, how can we best present this on the web page. I envision, a initial box size and reduced box size.

If the reduced box size divides the initial box size, we use binning otherwise it will be Fourier scaling. Also, I would include a javascript message to say what type of binning/scaling will be used.

I'll start a prototype of this.

I'm not sure why this became such a big discussion. My intentions was that the scaling option is ONLY available/used when you select RELION as the the output stack, in which case the Relion package is used to generate the particle stack (only box files are made using appion). Relion always performs Fourier windowing, even if you're scaling by 0.5
The makestack web gui options should change when you switch from "imagic" stack to "relion" stack to reflect this.

"The makestack web gui options should change when you switch from "imagic" stack to "relion" stack to reflect this." meaning, I already spent time at the last hackathon putting in the javascript to do this & update the output pixel size in real time as you change the output box size.

Well it broke some of the python, why should a feature be available for RELION and not in the standard, when we have to handle it in python either way.

I am on Gabe's side. If we insist on every package has the same function, we will end up with slow code that we write ourselves and no one with 100k or more particles will want to use any part of it.

Neil, if you do not want the feature to break on python side, put in validation to prevent it going to unhappy path. That should be enough.

As for the gui, I think give it the final pixel size and number of pixels in the boxed particle is the easiest for the user. As long as it is a separate option from real-space binning, it is good.

I am of the opinion that it is easier to have to work for both, it complicates things to have a feature for one thing and not the other.