Hi,
Using 4.7, I am seeing inconsistent numbers of duplicates removed when entering the pixel size manually, vs allowing it to be picked up from the micrographs.
Inputs:
The micrographs from which remove dups should get the pixel size come directly from a Patch Motion job with F-crop 1; the original pixel size of the movies was 0.5135.
If I leave the pixel size unset, 43,660 particles are removed. If I manually enter the pixel size of 0.5135, 59,990 particles are removed.
In the log for the first job, it says “Using micrograph pixel sizes from particle’s location/micrograph_psize_A”. This is a bit confusing to me - it suggests that it uses the micrograph pixel size from the particles, not from the supplied micrographs? What are the micrographs for, then?
It would be helpful for clarity I think if the actual pixel size being used for duplicate removal was printed numerically to the log - this would reduce the chance of confusion.
Cheers
Oli
EDIT:
Looking at the metadata:
It seems to be getting the wrong value from the particles - this seems like a bug?
I am also unsure why the micrograph pixel size associated with the particles is 1.02 - these particles were extracted directly from the F-crop 1 Patch Motion job, where the pixel size is 0.5135. They were extracted at bin 2, but that should not affect the micrograph pixel size?
Seems to be getting the micrograph dimensions as half as well? Or is that the Fourier crop factor?
That’s the Fourier crop factor I think - I think the particles somehow inherited these values from an earlier set of particles that were extracted from Fcrop 1/2 mics… a bit odd
Hey Oli,
Do you recall the original (non F-cropped) shape of the micrographs? I’m wondering if they were originally double the value reported in the image: "location/micrograph_shape": [2046, 2880]. If so I suspect you’d be right that the particles are somehow inheriting the entire location slot from an earlier set that came from F-crop 1/2 mics. Did you pick these particles from the non F-cropped micrograph from scratch, or did you instead re-extract the particles (from the non F-cropped mics) using an existing stack that was originally picked on the F-cropped particles?
Best,
Michael
Hi Michael,
Did you pick these particles from the non F-cropped micrograph from scratch, or did you instead re-extract the particles (from the non F-cropped mics) using an existing stack that was originally picked on the F-cropped particles?
The latter. The original particle stack was picked and extracted from F-cropped mics (dimensions match this micrograph_shape), and then I re-extracted those coords from non F-cropped mics prior to remove duplicates.
Shouldn’t remove duplicates take the pixel size from the supplied micrographs though? Or am I confused? Also shouldn’t the micrograph pixel size associated with the particles be reset when they are re-extracted?
Ah thanks very much for answering quickly.
Yes this is true – extract doesn’t do this right now, but it should. I’ve recorded this
Right now I believe the micrographs only have to be connected for particle datasets picked prior to 4.5, that don’t have the location/micrograph_psize_A field. Otherwise, new particle datasets picked in v4.5+ should be fully self-contained with the information they need, but due to the above bug they don’t have updated location info.
Best,
Michael
1 Like
Thanks Michael - would also be handy to print something to the log explaining this - e.g. a warning that the micrographs will be ignored (if particles have the location field), and telling the user what numerical value of pixel size is being used? Otherwise it is very easy to get confused
Agreed as well, these clarifications make it clearer what’s being used exactly. Recorded as well 
1 Like
