最近在分析从lfp解析出来的tiff格式,在分析LFToolbox0.2源码的时候我才发现python版本的lfp_reader和C版本的lfptools生成的raw是不同的,而且是lfptools似乎专门写了一个函数来制造这个不同的。利用raw2tiff把lfptools生成的图片转tiff然后用matlab读入,已经把python版本lfp_reader生成的raw用matlab直接读入,进行数值比较,相差一个16的倍数关系,这个都好理解了,而且imshow画出了只是亮度的差别(这里还有一个转置关系)。但是我就发现lfptools直接生成的raw无论是按照12bit还是按照16bit读入,都是与原图毫不相关的。这便是问题了。然后再看了raw2tiff的源码和lfptools的源码,又想起了上次提到的那个故意换位的问题了。
lfp进行一个这样的变换,我奇怪的是matlab代码读出的数据很多奇数,理论上应该都是16的倍数才对。
*image++ = (*ptr << 8) | (*(ptr+1) & 0xF0); *image++ = ((*(ptr+1) & 0x0F) << 12) | (*(ptr+2) << 4);
而raw2tiff中
... case TIFF_SHORT: for (i = 0; i < n_elem; i++) { X = ((uint16 *)buf1)[i]; Y = ((uint16 *)buf2)[i]; M1 += X, M2 += Y; D1 += X * X, D2 += Y * Y; K += X * Y; } break; ... M1 /= n_elem; M2 /= n_elem; D1 -= M1 * M1 * n_elem; D2 -= M2 * M2 * n_elem; K = (K - M1 * M2 * n_elem) / sqrt(D1 * D2);
还有很多不明确的地方