I did my thoughts on canon-profiles (aka styles) as well. i couldnt believe, these files arent hacked yet. there naturally is more than just contrast, saturation and so on. my thoughts by now ( i started yesterday a little bit analyzing files)
* a "simple and fast processing" inside the body is needed, therefore it must be a simple encoding.
* the pf3-files are ~double the size of the icc files found in the preset-style icc-path
example neutral with no adjustments
* icc file size - NS.ICC - 212kb
* pf3 file size - 425kb
* maybe for safety purposes the lut is written two times.
* maybe there s a inverted lut inside as well
* i saved a pf3-file with no changes three times with ~5secs difference. it seems, theres a timestamp in it, but the timestamp does not affect the encoding. nearly the end of the file a byte changes as well. a checksum? integrity check?
* the pf3-file must be rockstable to avoid crashing or deadlock the processing inside the body.
* the title and copyright arent saved plain, this leads me to the idea of a simple encoding. rle? difference? xor? not?
example links:
Canon Neutral SRGB 6091 ICC as XML (parts of it)pf3 neutral saved three timesBecause i dont know much about ICCs, i have to read more about ICC-LUTS to understand and recognize lut-data inside the hexview

maybe i find a byte/word (simply the clue) to decode the pf3-file. after this it should be much more simple to create own luts and pf3-files. Working only with the luma-curve is unsatisfactory.
by the way. did you tried combining your lumacurve with low-contrast-setting? is this affecting the max-luma from 235 to maybe 255?
simple toDos:
* decode title and copyright (we know the plaintext)
* decode the simple things (contrast, saturation hue aso)
* decode lumacurve
* decode 6axes-data
- i assume there are all in the beginning, then the lut comes.
regards chmee