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: #11 Commit Summary - da04410 <da04410> 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 <#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!