Increase RAW_DEBUG_TYPE limit

#780 Merged at c6ae928
Repository
hudson
Branch
raw_video_10bit_12bit
Author
  1. Daniel Fort
Reviewers
Description

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.

Comments (11)

  1. Alex

    Is the raw type 78 any different from 14? IIRC the modes were repeating after 16 on 5D3, but other cameras may be different.

    1. Alex

      Looking in the EOS M ROM I've found the following sequences:

      0xC0F37014, 0x00002300
      0xC0F37014, 0x0000000E
      0xC0F37014, 0x00000022
      0xC0F37014, 0x00000012
      

      5D3:

      0xC0F37014, 0x00000008
      0xC0F37014, 0x00000010
      0xC0F37014, 0x00000022
      

      5D3, lv_set_raw:

      (unless otherwise specified, the image has no obvious bad pixels and is not affected by digital ISO, e.g. raw histogram is the same as ISO 640 and 800)

      RSHD     => 0x0E (bad pixels, scaled by digital ISO)
      SHADE    => 0x04 (bad pixels, scaled by digital ISO)
      HIVSHD   => 0x08 (bad pixels, appears to fix some vertical stripes)
      ORBIT    => 0x0B (frozen raw image)
      DEFCORRE => 0x12 (aka lv_af_raw, scaled by digital ISO)
      CCD      => 0x10 (currently used)
      DEFMARK  => 0x07 (bad pixels)
      

      EOS M has no lv_set_raw, but the low-level routine is present (FF37AC80) and identical to 700D.

      700D, lv_set_raw has the same modes as 5D3, and two more:

      DEGEEN   => 0x1C
      SAFARI   => 0x23
      

      60D lv_set_raw:

      RSHD     => 0x0B
      SHADE    => 0x01
      HIVSHD   => 0x07
      ORBIT    => 0x09
      DEFCORRE => 0x04
      CCD      => 0x05 (currently used)
      DEFMARK  => 0x06
      

      5D3, all modes:

      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.

    2. Alex

      Found some more names on 70D (cc @nikfreak )

      0x03 DARKSUB
      0x04 SHADING
      0x05 TWOLINEADDSUB
      0x06 DEFC
      0x07 DEFMARK
      0x08 HIVSHD
      0x09 SMI
      0x0a PEPPER_CFIL
      0x0b ORBIT
      0x0c TASSEN
      0x0d PEPPER_WIN
      0x0e RSHD
      0x0f BEATON
      0x10 HEAD
      0x11 AFY
      0x12 DEFOE
      0x13 ORBBEN
      0x15 JUSMI
      0x16 SUSIE
      0x17 KIDS
      0x18 CHOFF
      0x19 CHGAIN
      0x1a CAMPOFF
      0x1b CAMPGAIN
      0x1c DEGEEN1
      0x1d DEGEEN2
      0x1e YOSSIE
      0x1f FURICORE
      0x22 INVALID
      0x22 PRE_FIFO
      0x23 SAFARI_IN
      0x24 DPCM_DEC
      0x29 SHREK_IN
      
  2. Daniel Fort author

    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.

    VRAM1.jpg

    1. Alex

      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?

      1. Daniel Fort author

        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: At top level:
        ../../src/raw.c:2069:6: error: #error Only implemented for CONFIG_EDMAC_RAW_SLURP.
             #error Only implemented for CONFIG_EDMAC_RAW_SLURP.
              ^
        ../../src/raw.c:2074:18: error: 'lv_raw_type' undeclared here (not in a function)
                 .priv = &lv_raw_type,
                          ^
        

        There are other compiling issues too. I'll update later.

        1. Daniel Fort author

          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.

  3. Daniel Fort author

    Some further testing on the EOSM and 700D:

    0x00002300 => bad

    0x0000000E => valid image stream

    0x00000022 => valid image stream

    0x00000012 => valid image stream