Skip to content
GitLab
Projects Groups Snippets
  • /
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in
  • Corryvreckan Corryvreckan
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 39
    • Issues 39
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 11
    • Merge requests 11
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
  • Deployments
    • Deployments
    • Environments
    • Releases
  • Packages and registries
    • Packages and registries
    • Container Registry
  • Monitor
    • Monitor
    • Incidents
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Issue
    • Repository
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • CorryvreckanCorryvreckan
  • CorryvreckanCorryvreckan
  • Merge requests
  • !116

Detector: update conversion from local coordinates to pixel counts etc.

  • Review changes

  • Download
  • Email patches
  • Plain diff
Merged Jens Kroeger requested to merge jekroege/corryvreckan:update_conversion_local_to_pixel_etc into master May 28, 2019
  • Overview 26
  • Commits 17
  • Pipelines 14
  • Changes 9

While working on the improvement of the clustering and DUT association, I realized that we're currently now completely consistent with how we're using the coordinates in pixel units.

In most places a pixel has the sub-pixel range [col, col+1], accordingly for the row. But then we have to add 1/2*pitch every now and again to make sure the conversion <int> to <double> is correct. This is prone to errors and we're making some errors here.

So after a discussion with @simonspa, the conclusion was that it's more natural to change it to [col-1/2,col+1/2].

Advantage:

  • We don't have to add 1/2 pitch anywhere: but the conversion from int to double is much safer now: double col = static_cast<double>(col_int) and nothing can go wrong.

Disadvantage:

  • pixel 0 extends into the negative range: [-0.5,0.5), all others are positive.
  • From double to int previously was simply int col = floor(dbl_col) and it is now int col = floor(dbl_col) + pitch/2 but this is hardly ever used whereas the opposite case (described above) is used all the time.

We only have to make sure we adjust all the affected histograms (range from -0.5 to Npixels-0.5 now and remove all the +1/2*pitch.


Here's a list of all modules being affected/not affected by this change. The affected ones should be those which make use of in-pixel information. All histograms like hitmaps which are filled only with int values can stay the same.

Affected (will have to look closer)

  • AnalysisCLICpix
  • AnalysisDUT
  • AnalysisEfficiency
  • AnalysisTelescope
  • AnalysisTimingATLASpix
  • Clustering4D
  • ClusteringSpatial
  • EtaCalculation
  • EtaCorrection
  • Tracking4D
  • TrackingSpatial

Not affected

  • AlignmentDUTResidual
  • AlignmentMillepede
  • AlignmentTrackChi2
  • AnalysisPowerPulsing
  • Dummy
  • EventLoaderATLASpix
  • EventLoaderCLICpix
  • EventLoaderCLICpix2
  • EventLoaderEUDAQ
  • EventLoaderEUDAQ2
  • EventLoaderMuPixTelescope
  • EventLoaderTimepix1
  • EventLoaderTimepix3
  • ImproveReferenceTimestamp
  • MaskCreator
  • MaskCreatorTimepix3
  • Metronome
  • OnlineMonitor
  • Prealignment
  • TestAlgorithm
  • TreeWriter
Edited Aug 30, 2019 by Jens Kroeger
Assignee
Assign to
Reviewers
Request review from
Time tracking
Source branch: update_conversion_local_to_pixel_etc