Spent a lot of time poring through the data last night, just for pf2 files. I think I can confirm that those bytes near the end are some kind of checksum, with the property ID being 0xfffe - Finalize (type 0x0004 ~ Long) according to @chris_overseas's list.
There's also a similar 32bit checksum just for copyright field data that appears at the beginning of the file after the 0x50535000 tag.EDIT: The 4 bytes after the 0x50535000 tag are actually the file length in bytes, not including the 12byte header.@jkaura noticed that 0x1009 is specifically Base Picture Style - Technicolor Cinestyle lists 0x0084 as it's value, because it's based on Neutral. I've tried putting in values higher than 86, since my latest OSX PSE software doesn't even list Monochrome as an option, but of course that checksum prevents me from re-encoding the file successfully without knowing how those values are generated.
EDIT: Oh, it's called a Longitudinal redundancy check. Working on the formula.In charting out the files, it seems that the tags go:
0x1009 0003 = Tag name followed by data type
0x0000 0004 = The actual length of the following data block (ie 04 = 4 bytes. The 3x20 color matrices are F0 = 240 bytes)
0x0000 0001 = Actual data, like 32bit Saturation Value
The caption field under propID 0x1002 is always a fixed 32 byte length, consisting of 31 character bytes plus a 00 ending byte.
The copyright field under propID 0x100A is a variable byte length, up to a max of 64 bytes, consisting of n character bytes plus a 00 ending byte.
Cinestyle actually matches the Canon structure closer than I thought, it's just that some of the tables and matrices are in a different order than Canon's.