Add a flipping function based on header information...?

[jonwright]

We often get edfimages that are mistakenly flipped during data collection. There is a header item which tells us this flipping was done. Can we add something to put them back to the original orientation, for example:

def headerFlip( hdr, data ):
# interpret <flip x : False,flip y : True>
x,y = hdr.split(",")
ret = data
if x.find("True")>0:
ret = numpy.fliplr( data )
if y.find("True")>0:
ret = numpy.flipud( data )
return ret

[kif]

On Fri, 05 May 2017 07:11:50 -0700 Jon Wright ***@***.***> wrote: We often get edfimages that are mistakenly flipped during data collection. There is a header item which tells us this flipping was done. Can we add something to put them back to the original orientation, for example: def headerFlip( hdr, data ): # interpret <flip x : False,flip y : True> x,y = hdr.split(",") ret = data if x.find("True")>0: ret = numpy.fliplr( data ) if y.find("True")>0: ret = numpy.flipud( data ) return ret

Is this a feature from LImA or specific from your beamline ?

[jonwright]

Hi Jerome This flip business should be common for all file formats that support putting a flip in the header. The code making the string is in: Lima/common/include/lima/SizeUtils.h : 412 Lima/control/src/CtImage.cpp : 1088 So when the image is flipped a header key:value pair is generated.

…

On 2017-05-06 10:36, Jonathan Wright wrote: Hi Seb, Manu In the edf headers we have strings like "<flip x : False,flip y : True>" Can you tell us where they come from? Is it spec or lima (all cameras) or frelon specific ? I would like to get something added in fabio so we can overcome the flip problem more automatically, so Jerome needs to know if it is an ID11 thing or if all ESRF cameras would give the same header? The problem of mystery flipping yesterday was solved with scanmode (thanks Manu!) Every time this happens it means all of the correction files (flood, spatial) are the wrong way up. This causes a lot of confusion! Thanks, Jon -------- Original Message -------- Subject: Re: [silx-kit/fabio] Add a flipping function based on header information...? (#113) Date: 2017-05-05 20:54 From: Jerome Kieffer ***@***.***> To: silx-kit/fabio ***@***.***> Cc: Jon Wright ***@***.***>, Author ***@***.***> Reply-To: silx-kit/fabio ***@***.***> On Fri, 05 May 2017 07:11:50 -0700 Jon Wright ***@***.***> wrote: > We often get edfimages that are mistakenly flipped during data collection. There is a header item which tells us this flipping was done. Can we add something to put them back to the original orientation, for example: > > def headerFlip( hdr, data ): > # interpret <flip x : False,flip y : True> > x,y = hdr.split(",") > ret = data > if x.find("True")>0: > ret = numpy.fliplr( data ) > if y.find("True")>0: > ret = numpy.flipud( data ) > return ret Is this a feature from LImA or specific from your beamline ? -- You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub [1], or mute the thread [2]. * Links: ------ [1] #113 (comment) [2] https://github.com/notifications/unsubscribe-auth/AAmk2nNbyOU-MbQ9TwvdmcCWYEvGQv0Oks5r23BigaJpZM4NR-Gy

[vallsv]

Hi. This kind of feature sounds fine, but it have to be taken very carefully. It can break a lot of things.

BTW do you have a sample for us?

[vallsv]

Lima looks to define this set of metadata (https://github.com/esrf-bliss/Lima/blob/master/control/src/CtImage.cpp#L1061):

• image_bin
• image_roi
• image_flip
• image_rotation

[jonwright]

We can collect a series of pictures to give testcases for the effect of binning, roi, flip and rotations. It seems you could eventually look at: bin 1x1, 1x2, 2x1, 2x2 flip 0 0 ; 0 1 ; 1 0 ; 1 1 rotation NONE, 270, 90, 180 ROI NONE, [X,Y,W,H] A lot of combinations to test. I guess the order is important, as doing rotation then flip is not the same as flip then rotation. Something like 3072 possibilities ({4*3*2 = 24} * {4*4*4*2 = 128}). Some of them don't work - image rotation together with an roi gives error messages. Hopefully a huge number of these should turn out to be the same result. The order of setting things is important for an roi: 1148.3DXRD> limaset f2ktaper image_roi 11 13 15 17 1149.3DXRD> limaset f2ktaper image_bin 2 1 1152.3DXRD> limaget f2ktaper image_roi - image_roi =_*5 *_13*_7 _*17 1153.3DXRD> limaset f2ktaper image_bin 1 1 1154.3DXRD> limaget f2ktaper image_roi - image_roi =_*10 *_13_*14 *_17 So the roi is adjusted to match the binning and then adjusted back again to become an even number. Resolving this in the general case is awful. At ID11 we only have a problem from flips (people figure out binning). These are a tiny subset of the big mess. Maybe it would be better to meet up with the BCU experts and discuss first?

[vallsv]

I think the main problem is not the implementation but the way to implement it and to stay compatible with the previous code. You must have still access to the raw data, and it also can create conceptual problem to convert or copy an image using the lib.

For data acquisition, we recommend not to apply software transformation on the image but to custom your display software if you want to see the image in a different way (then avoid flip and rot).

• Cause in this way you lose the close relation existing between the detector geometry and the data (pixels at different locations on your detector do not have the same meaning)
• And it's computation for nothing

But for a generic library, it can make sense while it is normalized.

[vallsv]

We talk about that with Jerome.

One of the solution would be to create a interpreted_data property to fabio images.

# reach the corrected image according to the metadata
data = img.interpreted_data

# reach the raw data (no changes from the current API)
data = img.data

But yet, we do not plan to apply this change. And we still have to find real acquired data using it.

[jonwright]

Hi Vallentin I am not sure what interpreted_data would give for an image where an ROI was applied? For now I still did not track down the issues on the LIMA side, so it is difficult to do anything concrete about the problem. There seemed to be some issues which showed up when we tried testing all combinations of flip/rotation/roi. The goal is to take a raw image (flat/spatial) and make it match to the collected data (roi/rotated/flipped/etc). In this way we would not need to prepare different calibration files whenever the data collection is adjusted.