convertCel(..., newChipType) updated 'chiptype' and 'header' fields in the CEL header, but not the datheader field. For example, a CEL header may look like:
Browse[2]> str(hdr)
List of 14
$ filename : chr "C:/Users/hb/R/win-library/3.3/AffymetrixDataTestFiles/ra
wData/FusionSDK_Test3/Test3/2.Calvin/Test3-1-121502.CEL"
$ version : int 1
$ cols : int 126
$ rows : int 126
$ total : int 15876
$ algorithm : chr "Percentile"
$ parameters : chr "Percentile:75;CellMargin:2;OutlierHigh:1.500;OutlierLow:
1.004;GridULX:154.000000;GridULY:164.000000;GridURX:995.000000;GridURY:"| __trun
cated__
$ chiptype : chr "Test3"
$ header : chr ""
$ datheader : chr "[12..40151] Fetal 3:CLS=1167 RWS=1167 XIN=3 YIN=3 VE=
17 2.0 08/16/01 17:28:31 \024 \024 Test3.1sq \024 \024 \02"| __trun
cated__
$ librarypackage: chr ""
$ cellmargin : int 2
$ noutliers : int 5
$ nmasked : int 0
Note how the chip type is encoded also in the datheader fields. In other words, depending on CEL file/header, the output may or may not get the new chip type set.
It looks like .getCelHeaderV4() is the bad guy. For Calvin/v1 CEL files, .getCelHeaderV4(header) will re-read the CEL header, use it to override the header already set.
convertCel(..., newChipType)
updated 'chiptype' and 'header' fields in the CEL header, but not thedatheader
field. For example, a CEL header may look like:Note how the chip type is encoded also in the
datheader
fields. In other words, depending on CEL file/header, the output may or may not get the new chip type set.