펑키 파일 타임 스탬프 형식을 해독하는 방법에 대한 팁?

Question

우리는 Windows 7/Vista 플랫폼에서 실행되는 독점적 인 이미지 분석 소프트웨어가있는 과학 장비 모음을 보유하고 있습니다. 이 소프트웨어는 품질 관리 메트릭 컬렉션을 바이너리 형식으로 유지합니다. 진취적인 프로그래머는 python 라이브러리를 작성하여 이러한 메트릭 파일에서 데이터를 가져오고 분류했습니다. 저는 이것을 사용하고 있지만, 해독에 어려움을 겪고있는 큰 관심거리가 있습니다. 라이브러리 코드에서 :

def parse_binary(self): 
    bs = self.bs 

    # Extraction Metrics (ExtractionMetricsOut.bin) 
    # Contains extraction metrics such as fwhm (full width at half maximum) scores and raw intensities 
    # Format: 
    # byte 0: file version number (2) 
    # byte 1: length of each record 
    # bytes (N * 38 + 2) - (N *38 + 39): record: 
    #  2 bytes: lane number (uint16) 
    #  2 bytes: tile number (uint16) 
    #  2 bytes: cycle number (uint16) 
    #  4 x 4 bytes: fwhm scores (float) for channel [A, C, G, T] respectively 
    #  2 x 4 bytes: intensities (uint16) for channel [A, C, G, T] respectively 
    #---->8 bytes: date/time of CIF creation --> 2 x 4 bytes for date and timestamp 
    # ...Where N is the record index 
     self.apparent_file_version = bs.read('uintle:8') 
     self.check_version(self.apparent_file_version) 

     recordlen = bs.read('uintle:8') # length of each record 

     for i in range(0,((bs.len)/(recordlen * 8))): # record length in bits 
      #OMITTED: obtain various data 
      #... 
      # 8 bytes: date/time of CIF creation 
      self.data['datetime'].append(bs.read('uintle:32')) 
      self.data['timestamp'].append(bs.read('uintle:32')) 

self.df = pandas.DataFrame(self.data) 

파이썬 콘솔에서 데이터를 검사 할 때 'datetime'데이터는 전혀 이해가되지 않습니다. 그러나 타임 스탬프 데이터가 훨씬 더 흥미 롭다 :

"exmets는"십일일의 과정에 대한 통계를 포함하는 팬더 dataframe 인 6 월 5 일 2013 년 6 월 (16) 2013 년 :

>>> len(exmets.data['timestamp']) 
226559 
>>> len(exmets.data['datetime']) 
226559 

>>> exmets.data['datetime'][1:10] 
[2861233716L, 2934210013L, 2764566050L, 2864234016L, 2767136307L, 2817880381L, 2936700262L, 2820490642L, 2769576551L, 2866944287L] 

>>> exmets.data['datetime'][100000:100010] 
[4093949428L, 4104309713L, 4090699103L, 4094859519L, 4094289462L, 4098919713L, 4104359713L, 4104359713L, 4132262259L, 4150663099L] 

내가 말했듯이, 'datetime'은 꽤 이상합니다. 그러나 '타임 스탬프는'훨씬 더 일반적인 것 같다

>>>exmets.data['timestamp'][1:10] 
[2295344086L, 2295344086L, 2295344086L, 2295344086L, 2295344086L, 2295344086L, 2295344086L, 2295344086L, 2295344086L] 

    >>>exmets.data['timestamp'][100000:100010] 
[2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L, 2295345531L] 

    >>>exmets.data['timestamp'][226549:226559] 
[2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L, 2295347466L] 

그래서 처음부터 끝까지 정기적으로 진행이있다, 그러나 당신이이 숫자 평균 초를 가정하면, 년에 단 한 시간이면 동일시 2296347466 - 2295344086 = 3380의 차이가있다 용어의 초. 기계가 11 일간의 기간 동안 데이터를 생성하고 있었으므로 초가 이것을 잘못 가정하는 것으로 보입니다.

이것을 해독하는 방법에 대한 아이디어가 있으십니까?

Answer 1

나는 그 라이브러리를 썼다! :)

중요 업데이트 Illumina의 연락 후, 나는 두 가지 계시를 통보했다

:

1. 내가 날짜와 시간에 대한 두 개의 필드를 구문 분석 할 수 잘못; 실제로는 하나의 64 비트 부호있는 정수입니다.

2. 그 64 비트 부호있는 정수는 그레고리 안 1 AD (파이썬의 datetime.datetime (1,1,1))에서 시작하여 100 나노초 씩 증가하는 C# DateTime입니다.

   ... 대답은 다음

이전 당신은 대답에 너무 가까이 있습니다. 당신의 제공 번호를 사용하여,이 체크 아웃 : 즉

In [59]: 2296347466 - 2295344086 
Out[59]: 1003380 

In [65]: 1003380.0/24/60/60 
Out[65]: 11.613194444444444 

, 그것은 초에입니다!

아직 타임 스탬프 형식을 이해하지 못하기 때문에 완전한 대답은 아니지만 지금까지 내가 아는 것을 공유 할 것이라고 생각했습니다.

시퀀서가 데이터를 바이너리 파일로 출력하는 방법을 고려하여 신비의 일부를 추론 할 수 있습니다.

어떻게 바이너리

하나 중요한 것은 Illumina의 시퀀서에 대해 알 수있는 바이너리에 표시되는 내용을 우리에게, 어리석은 인간, 비트 비선형 느낌이다에 Illumina의 시퀀서 출력 데이터. 타임 스탬프별로 정렬 할 때 순환 # 2/타일 1101에 대한 정보가주기 # 1/타일 1103 (예 :) 앞에 표시되는 것은 정상입니다.

가장 큰 원인은 시퀀서가 정보를 파일로 계속 펌프하지 않지만 버퍼에 여러 가지 물건을 저장하고 모든 것을 한 번에 작성한다는 것입니다.

타임 스탬프에 표시되는 내용과 상당히 일치합니다. 즉, 타임 스탬프는 해당 타일이 이미지화 된 순간이 아니라 버퍼의 누적 된 데이터가 디스크에 기록 된 시점을 나타냅니다.

이 시도 :

print len(exmets.df.timestamp.unique()) 
print len(exmets.df.datetime.unique()) 

당신은 고유의 날짜 시간보다 훨씬 적은 고유의 타임 스탬프를 볼 수 있습니다. 또한 타임 스탬프에는 매우 규칙적인 간격이있을 수 있습니다. 우리는 일하는 곳에서 11 일간의 일을하지 않으며, 단지 36 시간 정도만 일하므로 내 데이터의 간격은 약 5 초 정도 떨어져 있습니다. (귀하의 데이터가 어떻게 보이는지 알고 싶습니다.)

그래서이 시간 기록은 참조 할 수있는 신기원을 인식하지 못한다는 점을 제외하고는이 시간 기록이 초 단위가 아니 었습니다. 내 첫 번째 추측은 1601 년 1 월 1 일 00:00:00 UTC 이후 100 나노초 단위로 측정 한 NTFS 였지만 전혀 작동하지 않습니다.