Just a suggestion. I keep finding useable RAW_DEBUG_TYPE above the 64 limit. There probably isn't anything to gain going beyond 128. Note that there are comments in raw.c referring to cameras using PREFERRED_RAW_TYPE 78 so this is another reason to increase this limit.
Is the raw type 78 any different from 14? IIRC the modes were repeating after 16 on 5D3, but other cameras may be different.
78 and 14 look the same on the EOSM. So are you saying that they repeat every 64 steps? That's not what I discovered when checking rbrune's EOSM mv1080 work in progress. Only the following values worked, 7, 11, 48, 50, 75, 80, 87. All others resulted in a "Raw detect error."
0x00 => valid image stream in some unknown format
0x01 => bad
0x02 => scaled by digital ISO (DEFCORRE?)
0x03 => bad
0x04 => see SHADE
0x05 => bad
0x06 => bad
0x07 => see DEFMARK
0x08 => see HIVSHD
0x09 => bad
0x0A => bad
0x0B => bad
0x0C => bad
0x0D => bad
0x0E => see RSHD
0x0F => bad
0x10 => see CCD
0x11 => bad
0x12 => see DEFCORRE
0x13 => bad
0x14 => valid image stream in some unknown format (different from 0)
0x15 => bad
0x16 => bad
0x17 => bad pixels
0x18 => bad
0x19 => bad
0x1A => bad
0x1B => bad
0x1C => bad pixels
0x1D => bad
0x1E => bad pixels
0x1F => bad
0x20 => valid image stream in some compressed format?
0x21 => bad
0x22 => clean image
0x23 => bad
0x24 => bad
0x25 => bad
0x26 => bad
0x27 => bad pixels
0x28 => valid image stream in some compressed format?
0x29 => bad
0x2A => some strange column artifacts
0x2B => bad
0x2C => bad
0x2D => bad
0x2E => some strange posterization
0x2F => bad
0x30 => valid image stream in some compressed format?
0x31 => bad
0x32 => clean image
0x33 => bad
0x34 => valid image stream in some unknown format
0x35 => bad
0x36 => bad
0x37 => bad pixels
0x38 => valid image stream with some missing columns?!
0x39 => same
0x3A => clean image
0x3B => bad
0x3C => bad pixels, strange column artifacts (like 0x2A, but with bad pixels)
0x3D => bad
0x3E => posterization (same as 46)
0x3F => bad
0x40 - 0x7F => same as 0x00 - 0x3F (checked most good modes and some bad modes)
So, at least on 5D3, the modes appear to repeat after 64,
but that doesn't mean other cameras couldn't have more modes. In particular,
the pair (0xC0F37014, 0x00002300) suggests this register may be a bit field,
so a more generic configuration would be:
.max = 0xFFFF,
.unit = UNIT_HEX,
And writing the raw type in hex should help finding some bit patterns.
In menu, UNIT_HEX will also enable caret-based editing in hex format.
Wow, this is amazing. Uh, but does that mean that now I've got 65,535 instead of "just" 128 PREFERRED_RAW_TYPE's to look into? (Hope the pattern does repeat.)
Tested the new changes and it works great.
Right, but I expect some of the bits to be independent of others. In particular, you could check whether 0x2300 gives a valid image.
Does the 700D have the same valid raw streams as the M?
I haven't compared them. Need to improve my note taking when running these tests.
Having a tough time checking whether 0x2300 gives a valid image. On the EOSM it doesn't. I can't compile the 700D.
../../src/raw.c:Attoplevel:../../src/raw.c:2069:6:error:#errorOnlyimplementedforCONFIG_EDMAC_RAW_SLURP.#error Only implemented for CONFIG_EDMAC_RAW_SLURP.^../../src/raw.c:2074:18:error:'lv_raw_type'undeclaredhere(notinafunction).priv=&lv_raw_type,^
There are other compiling issues too. I'll update later.
Looked into it some more and it seems that in order to "#define RAW_DEBUG_TYPE" the platform needs CONFIG_EDMAC_RAW_SLURP and that hasn't been done for the 700D yet so I'm not able to check whether 0x2300 gives a valid image on the 700D.
Got CONFIG_EDMAC_RAW_SLURP working on the 700D and can report that 0x2300 does not give a valid image on either the EOSM or 700D.