Open takluyver opened 5 years ago
Great minds think alike :0). - Yes that is correct. I only need those for future use of karabo-data geometry
OK, great. I'll try to come up with a clean way to get those.
BTW. What do you think about moving the whole geoAssembler into karabo_data? Maybe without the qt stuff. Eventually it would be part of the geometry treatment.
I'm not ruling it out, but I think geoAssembler makes a fairly nice standalone package.
I'm also keen to limit the scope of karabo_data, because the bigger it gets, the more people will say "I don't need all that, I'll just read the HDF5 files directly", and either wind up duplicating the work we've done with to process the files, or getting the data misaligned because they haven't done all the fiddly stuff with the index.
With hindsight, maybe it would have made more sense for the detector geometry machinery to be part of geoAssembler rather than karabo_data. But I think we tend to fall into organising projects by who works on them, and it's been good that you and I can review each other's geometry code a bit. So maybe accidentally splitting it over two projects has worked out nicely.
geoAssembler needs to record modified quadrant positions. At present, it reverse engineers them from the tile corner positions kept by karabo_data and the geometry file with the module/tile offsets. I think it would make more sense for karabo_data to be able to provide the necessary information.
@antarcticrainforest - what specifically do the quadrant positions need to be? Is it just whatever should be given back to the
from_quad_positions
orfrom_hdf5_file_and_quad_positions
methods?