Project

General

Profile

Actions

Bug #705

closed

Unable to create a new stack from a stack with a different preset

Added by Anna-Clare Milazzo over 14 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Python scripting
Target version:
Start date:
06/24/2010
Due date:
% Done:

0%

Estimated time:
Affected Version:
Appion/Leginon 2.2.0
Show in known bugs:
Yes
Workaround:

Description

Error output is below. I've tried even making a new stack out of the same stack with the same preset which gives me the same error.

.. Querying database for preset 'upload1' images from session '10jun17n50a' ... 
... Found 127 images in 418.01 msec 
... Remove processed images 
skipping images 
................ 
!!! WARNING: skipped 17 of 127 images 
... [[ no reprocess | 17 rejected | wrong tilt | in donedict ]] 
... Process images old to new 
Traceback (most recent call last): 
File "/opt/appion/bin/makestack2.py", line 1090, in ? 
makeStack.run() 
File "/usr/lib64/python2.4/site-packages/appionlib/appionLoop2.py", line 45, in run 
self._getAllImages() 
File "/usr/lib64/python2.4/site-packages/appionlib/appionLoop2.py", line 502, in _getAllImages 
self.params['apix'] = apDatabase.getPixelSize(self.imgtree[0]) 
File "/usr/lib64/python2.4/site-packages/appionlib/apDatabase.py", line 233, in getPixelSize 
pixelsizedata = pixelsizedatas[i] 
IndexError: list index out of range 
Actions #1

Updated by Neil Voss over 14 years ago

  • Category set to Python scripting
  • Status changed from New to Assigned
  • Target version set to Appion/Leginon 2.1.0
  • Affected Version changed from Appion/Leginon 2.0.1 to Pre-2.0
  • Show in known bugs changed from No to Yes
Actions #2

Updated by Neil Voss over 14 years ago

  • Status changed from Assigned to In Code Review
  • Assignee changed from Neil Voss to Anna-Clare Milazzo

Hi Anna, it works now, but you will have to test using the trunk code here at AMI. We will have to discuss about whether we should port it to the branch.

Actions #3

Updated by Neil Voss over 14 years ago

Actually the error you are getting is that is does not know the pixel size...

Actions #4

Updated by Neil Voss over 14 years ago

When I updated the database for your new pixelsize of 1.45, changed all the dates of the pixelsize calibration to the current time, so when python went to get the pixelsize for your images all the calibrations came after the image collection, so it failed.

You're stack making should work on the branch now since it was a database error, but I found another bug in r14427 that will break later on in the script.

Actions #5

Updated by Anna-Clare Milazzo about 14 years ago

I can't seem to test this because if I use http://cronus3.scripps.edu/~amiguest2/myamiweb/index.php? from my amiguest2 account, I cannot seem to log into goby as amilazzo to test the stack creation and amiguest2 does not have an account on goby.

Actions #6

Updated by Amber Herold about 14 years ago

  • Status changed from In Code Review to In Test
Actions #7

Updated by Anna-Clare Milazzo about 14 years ago

Hi Amber,

Seems to be partially working now testing this off-site and logged into goby with the same preset. Trying to create a stack with a different preset failed though-- do I need to test this over at AMI logged in as amiguest2?

Actions #8

Updated by Amber Herold about 14 years ago

We decided to wait for Goby to be updated with 2.1 to test this. It is low risk for other users.
This should not prevent release of 2.1.

Actions #9

Updated by Scott Stagg almost 14 years ago

During these changes, I think something else was broken unless my database schema is not up to date. I am getting the following error:

Traceback (most recent call last):
  File "/home/sstagg/myami_dev/appion/bin/makestack2.py", line 1260, in <module>
    makeStack.run()
  File "/home/sstagg/myami_dev/appion/appionlib/appionLoop2.py", line 70, in run
    results = self.loopProcessImage(imgdata)
  File "/home/sstagg/myami_dev/appion/appionlib/appionLoop2.py", line 116, in loopProcessImage
    return self.processImage(imgdata)
  File "/home/sstagg/myami_dev/appion/bin/makestack2.py", line 1099, in processImage
    self.boxedpartdatas, self.imgstackfile, self.partmeantree = self.boxParticlesFromImage(imgdata)
  File "/home/sstagg/myami_dev/appion/bin/makestack2.py", line 192, in boxParticlesFromImage
    shiftdata = {'shiftx':shiftpeak['shift'][0], 'shifty':shiftpeak['shift'][1], 'scale':shiftpeak['scalefactor']}
  File "/home/sstagg/myami_dev/sinedon/data.py", line 492, in __getitem__
    return self.special_getitem(key, dereference=True)
  File "/home/sstagg/myami_dev/sinedon/data.py", line 471, in special_getitem
    value = super(Data, self).__getitem__(key)

This seems to be coming from these lines starting at line 188 of current trunk:
        if self.params['defocpair'] is True and self.params['selectionid'] is not None:
            # using defocal pairs and particle picks
            partdatas, shiftpeak = apParticle.getDefocPairParticles(imgdata, self.params['selectionid'], self.params['particlelabel'])
            shiftdata = {'shiftx':shiftpeak['shift'][0], 'shifty':shiftpeak['shift'][1], 'scale':shiftpeak['scalefactor']}

These lines are used if you specify a pick run from a sibling (not a stack) and click the "Use defocal pairs" option. Does anyone else have this error or is a a legitimate bug?

Actions #10

Updated by Anchi Cheng over 13 years ago

  • Assignee changed from Anna-Clare Milazzo to Neil Voss
  • Priority changed from High to Normal

Neil,

I have a question about your revision r14427. It does recordShift instead of insertShift. Is the saved file just for debug or is it necessary for something. The function getShiftFromImage is been call by both particleLoop2.py and makestack2.py. The former
would pass in 'ef' in standard case but the latter pass in 'en'.

Actions #11

Updated by Neil Voss over 13 years ago

I cannot see in the code where you are talking about this...

I created this for the fake defocal pairs (actually exposure pairs) from the DDD for Anna-Clare. So you create a stack from one defocal pair and want the second. We were having a problem that the cross-correlation between the exposure pairs. The cross-correlation should be (0,0) since it is the exact same image with different subimages included and we were getting values like (10,15) pixels or more screwing everything up, so that is why I wrote the output file.

Actions #12

Updated by Neil Voss over 10 years ago

  • Status changed from In Test to Closed
  • Assignee deleted (Neil Voss)
  • Affected Version changed from Pre-2.0 to Appion/Leginon 2.2.0
Actions

Also available in: Atom PDF