fixing dt time calculation

[mgalenb]

I believe the dt calculation is wrong in the code.

The fractions need be divided by 4 and the two bits for IRIG removed. This is not well documented in the phantom documentation but I checked the time from trigger using the phantom PCC software

Frame 0:

Frame 299:

base code:

new code:

Here is the new dt calculation

for i in eachindex(dt)
     fracstart = read(f, UInt32)/4/2^30
     secstart = read(f, UInt32)
     dt[i] =
          (secstart - cine.TriggerTime.seconds) +
          ((fracstart - cine.TriggerTime.fractions/4/2^30) )
end

[stillyslalom]

Good catch! I’ll take a look at this tomorrow. All my recordings are less than a second, which is probably why I didn’t run into this bug.

On Wed, May 22, 2024 at 10:47 PM mgalenb @.***> wrote:

I believe the dt calculation is wrong in the code.

The fractions need be divided by 4 and the two bits for IRIG removed. This is not well documented in the phantom documentation but I checked the time from trigger using the phantom PCC software

Frame 0: Screenshot.2024-05-22.at.9.23.30.PM.png (view on web) https://github.com/stillyslalom/CineFiles.jl/assets/6004917/8bcb7e45-53de-4f57-9efe-da9416d1b620

Frame 299: Screenshot.2024-05-22.at.9.24.56.PM.png (view on web) https://github.com/stillyslalom/CineFiles.jl/assets/6004917/5efb1bcd-b918-4eb8-a9e2-32ef7976aeef

base code: Screenshot.2024-05-22.at.9.18.30.PM.png (view on web) https://github.com/stillyslalom/CineFiles.jl/assets/6004917/e96e01ef-c734-415b-920c-fe499987d5ec

new code: Screenshot.2024-05-22.at.9.06.07.PM.png (view on web) https://github.com/stillyslalom/CineFiles.jl/assets/6004917/942eca48-71b1-4855-b3d2-f4a61fbf4be2

Here is the new dt calculation

for i in eachindex(dt) fracstart = read(f, UInt32)/4/2^30 secstart = read(f, UInt32) dt[i] = (secstart - cine.TriggerTime.seconds) + ((fracstart - cine.TriggerTime.fractions/4/2^30) )end

---

You can view, comment on, or merge this pull request online at:

https://github.com/stillyslalom/CineFiles.jl/pull/11 Commit Summary

• da04410 https://github.com/stillyslalom/CineFiles.jl/pull/11/commits/da04410ec5356da9a6f58fc2df0f954fe5346869 fix dt time calculation

File Changes

(1 file https://github.com/stillyslalom/CineFiles.jl/pull/11/files)

• M src/CineFiles.jl https://github.com/stillyslalom/CineFiles.jl/pull/11/files#diff-cf7d09012d90192dde109fa21544ca0efc4ca270eb772194e50f771d4531ff0c (4)

Patch Links:

• https://github.com/stillyslalom/CineFiles.jl/pull/11.patch
• https://github.com/stillyslalom/CineFiles.jl/pull/11.diff

— Reply to this email directly, view it on GitHub https://github.com/stillyslalom/CineFiles.jl/pull/11, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABA73GFFCDI2ZUBWHWXMQRLZDVYFZAVCNFSM6AAAAABIE3RZL6VHI2DSMVQWIX3LMV43ASLTON2WKOZSGMYTCOJTGE4DKMY . You are receiving this because you are subscribed to this thread.Message ID: @.***>

[stillyslalom]

Can you produce a sample cine file (minimum resolution, minimum number of frames) that gives incorrect timestamps and add it to test/data/? You're welcome to add a corresponding test, otherwise I'll take care of it.

[mgalenb]

I added a dt_test.cine to /test/data and checked the new dt calc vs the PCC software and it checks out. I havent written a test before however so not sure how to do that?

[mgalenb]

actually, the original code is correct also..... maybe there is something about the other cine file I was using....looking into it

[mgalenb]

ok I think it is related to software version. I have a cine save with version 787. this cine file gives two different dt depending on the base or changed code.

then I have just saved a cine and put into test/data with version 804. this cine gives the same dt using either code...looking into this more. the older version save is done using labview SDK the cine I put into test/data was created using PCC v3.8.804.6

[mgalenb]

also it now occurs to me that

1/4/(2^30) = 1/(2^32)

lol sorry for the spam

let me try to reproduce the issue using a older cine file version....

[mgalenb]

ok I figured it out. it had to do with subtracting fracstart and TriggerTime.fractions which are UInt32. this produced another UInt32 which would not have the correct fraction (see 3 column plot on left). the bottom plot shows cf.header.dt

the solution is to convert them to float64 (by dividing by 2^32) and then subtracting (see plot on the right)

the problem was a bit tricky because checking the first and last value in cf.header.dt sometimes gave the correct answer depending on TriggerTime. I only realized the problem when I plotted cf.header.dt for test/data/dt_test.cine

sorry for the original red herring!