search

ComputationalRadiationPhysics / jungfrau-photoncounter

Conversion of Jungfrau pixel detector data to photon count rate
GNU General Public License v3.0
2 stars 2 forks source link

Upload presentation file from TUD course #14

Closed bussmann closed 7 years ago

bussmann commented 7 years ago

Please upload your presentation and the accompanying data.

kloppstock commented 7 years ago

Please find our presentation here and the images generated by our program here (both are placed in the /doc/doc/presentation_2017_01_31 directory).

@sredford , our input images seem to be slightliy misplaced (as are the output images). Is this a problem with the data our is our loading algorithm working incorrectly?

sredford commented 7 years ago

I looked at the images generated by your program, I agree that they are not quite right.

First of all, I guess you noticed the vertical flip between these images and the reference? In our orientation, the half-ring should be on top and the noisy corner should be bottom right.

The more important problem is the 'wrap' of your images left to right. in output_0 I think this is already present - the brighter strip on the left of your images should be on the right. The wrap is increasing as I look through output_1, _2, _3 and is significant at _999.

In _999 I also see a top to bottom wrap.

I think you must have a looping error. This would also explain why the ring seems slightly squashed to me. The data we are using is the same, so it's hard to imagine that this is the problem. The input images also have this wrap error, does that point to a mistake in your loading of the data? Or the filling of the images?

Are you taking care of the header of each frame? The header should not be plotted in the image.

de-narm commented 7 years ago

The vertical flip is due to our drawing function, we start from the upper right corner whlie the reference starts from the lower right one. Since we were in a hurry to finish the presentation, we only rotated the image so it's mory easily to comapre with the reference. Rotating the output should not pose any difficulties.

Concerning the wrap, it's indeed the header. The .pdf didn't mention one, so we assumed there were none. We just did the math again and it seems like 16 byte per image? Previously we only checked the pedestal maps, which seem to not have one. What are they for exactly?

sredford commented 7 years ago

Each frame consists of: uint64_t framenumber uint64_t bunchid uint16_t imagedata[NCH]

This gives space in the header of each event for necessary information for eventual SwissFEL operation. In the data you have, I'm not sure what's in there. It shouldn't concern you anyway, just skip the 2x64 and then load the image array. I think the data file you have is exactly 10,000 frames long, so you can check size-wise that you have the correct number of bytes / bits per frame.

de-narm commented 7 years ago

Skipping it already did the trick. Does the next program expect us to keep it or should we drop it completely? I'm not sure whether or not everything with it is done before or after the data reaches us.

sredford commented 7 years ago

I also don't know about the order. @mbrueckner-psi ?

mbrueckner-psi commented 7 years ago

Well, as far as I know at the moment there is no special next program beside writing it to disk. Since I didn't look into your implementation, yet I don't know how complicated it is to keep header and data together without sending both (header+data) to the GPU.

de-narm commented 7 years ago

We'd send both anyway, it's way faster to copy everything and just skip the header in our calculations than it would be to drop the header for every frame beforehand. We only need to know whether or not to include the header in our resulting data.

mbrueckner-psi commented 7 years ago

Include the header since we need it afterwards anyway.