supplierdeeply

How to prevent the writing of JPEGs

  • 6 Replies
  • 1129 Views
*

Offline srsa_4c

  • ******
  • 3133
  • Publish
    How to prevent the writing of JPEGs
    « on: 03 / January / 2012, 19:22:46 »
    Advertisements
    As far as I know, it's currently not possible to do remote capture (via ptp) without SD-card wear. There may be eventproc's for that, but I haven't tried to play with those.
    The following is the result of a partial investigation of the picture recording process. The result was not tested much, but I think it should work.

    Investigated and tested on the A420, VxWorks.

    There are several tasks involved in the shooting process. As my current goal was to catch the creation and writing of the jpeg, I have narrowed down the search to the following tasks:
    - CaptSeqTask
    - DvlpSeqTask (which stands for DevelopSequenceTask)
    - FileWriteTask
    - FileScheduleTask

    I already knew that FileScheduleTask and FileWriteTask is absent when movie record is in progress, so I suspected that they are related to the writing of jpg's. This turned out to be true.

    The jpeg creation process goes like this:
    - CaptSeqTask's main loop enters case 1 (shooting). This routine is already patched to include our RAW, remote and NR-prevention hooks. There's a subroutine here which posts a message (1) to DvlpSeqTask (not fully investigated, it seems to pick up some procase values), and later (near its end) another subroutine, which posts a different message (0) to that task. The latter message causes the engine to start processing.
    - DvlpSeqTask is responsible for the RAW development process. Once the engine has finished, the task sets an eventflag which is owned by FileWriteTask. A lot of other things also happen, but I'm happy I got this figured out.
    - FileWriteTask and FileScheduleTask play together. The latter is a mess for me, fortunately FileWriteTask's code is simpler. What it does is roughly the following:
     - The appearance of the above mentioned eventflag (1) wakes up the task.
     - Now there's data in the task's data area (I don't know where that comes from, it's the filename, pointers to the exif, the main jpeg and other stuff)
     - The task has a main routine with a case structure.
      - case 0: creates and opens the file for writing
      - case 1,2,3: writes into the file then closes it
     - After it has finished, the (1) flag is cleared

    After a lot of trial and error (brute force methods like preventing the task to process don't work because of the mess of eventflags, semaphores, etc), I found a simple method:
    I changed the filename to "/null" which is the /dev/null of VxWorks. With this, open() returns a valid file handle, and nothing is written to the card (and it's also fast).
    As the file name is checked several times for correctness - it has to start with "A/" - I had to dig down to open(), and change its first parameter. Fortunately, it's only a BL away.

    This place looks like a good candidate for a jpeg hook - for ptp.

    With this method, the file counter is incremented as usual.

    Now the problem: does anybody know whether there is a /dev/null for DryOS? If not (or not found), the solution might involve bigger changes. Or it has to be done differently...


    Looked at FileWriteTask of a DryOS camera (SX100), it's roughly similar (it has more states).

    *

    Offline reyalp

    • ******
    • 9952
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #1 on: 03 / January / 2012, 20:33:29 »
    Nice. Note that on vxworks, you could easily set up your own device that appears under A, we already do this for diskboot in drv_self_hide.   You can also look at the /tyCo/0 hook for console output. Note that you could make this driver actually eat the data and send it off over ptp (or rather buffer it and block until the PC grabs it, since the camera can't initiate data transfer) Don't know if that would be simpler than grabbing it out of memory...

    vxworks documentation may be easily found with google.

    I would guess that setting up a driver on DryOS is similar, but documentation is scarce :)
    I don't see an references to anything that looks like /dev/null. There is /_term and termDeviceCreate
    Don't forget what the H stands for.

    *

    Offline srsa_4c

    • ******
    • 3133
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #2 on: 03 / January / 2012, 22:10:07 »
    Nice. Note that on vxworks, you could easily set up your own device that appears under A, we already do this for diskboot in drv_self_hide.   You can also look at the /tyCo/0 hook for console output. Note that you could make this driver actually eat the data and send it off over ptp (or rather buffer it and block until the PC grabs it, since the camera can't initiate data transfer) Don't know if that would be simpler than grabbing it out of memory...
    Thx for the suggestions. Using a device with a name that passes the name check could spare the duplication of a few routines and would look elegant. But I currently barely know anything about devices  :blink: ...

    For now, I leave this as a proof (unless there's more interest). This will need to be extended for DryOS, and I guess it could be integrated into the ptp code somehow, someday.

    Quote
    vxworks documentation may be easily found with google.
    I have collected several manuals and yes, without them this might not have happened (had to look up eventflags this time).
    Quote
    I would guess that setting up a driver on DryOS is similar, but documentation is scarce :)
    I don't see an references to anything that looks like /dev/null. There is /_term and termDeviceCreate
    A quick search yielded nothing useful. Maybe somebody from the Magic Lantern people knows more :)

    I've placed the relevant parts of the code here: http://chdk.wikia.com/wiki/User:Srsa_4c/A420_FileWriteTask

    *

    Offline reyalp

    • ******
    • 9952
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #3 on: 03 / January / 2012, 22:21:19 »
    Thx for the suggestions. Using a device with a name that passes the name check could spare the duplication of a few routines and would look elegant. But I currently barely know anything about devices  :blink: ...
    If you want to just prevent writing, and grab the data elsewhere, you could probably just copy the device struct from the null device.

    edit:
    FWIW, I was unable to open /_term with open() in dryos, so maybe dryos devices are not so similar to vxworks ones.
    « Last Edit: 03 / January / 2012, 22:24:37 by reyalp »
    Don't forget what the H stands for.


    *

    Offline srsa_4c

    • ******
    • 3133
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #4 on: 03 / January / 2012, 22:34:38 »
    If you want to just prevent writing, and grab the data elsewhere, you could probably just copy the device struct from the null device.
    Not a bad idea. Where could I find it? In the firmware, there's only one instance of "/null", and I'm not sure if it belongs to the device itself...
    Quote
    edit:
    FWIW, I was unable to open /_term with open() in dryos, so maybe dryos devices are not so similar to vxworks ones.
    That may mean it has to be done the hard way (modifying the code all over). Or maybe a different approach will be needed...

    Edit:
    hmmm, I see: DRV_struct = _iosDevFind("/tyCo/0", 0); in /platform/generic/main.c
    « Last Edit: 03 / January / 2012, 22:38:21 by srsa_4c »

    *

    Offline reyalp

    • ******
    • 9952
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #5 on: 03 / January / 2012, 22:55:39 »
    hmmm, I see: DRV_struct = _iosDevFind("/tyCo/0", 0); in /platform/generic/main.c
    Yes, I'm thinking that structure should have the pointers you need for _iosDrvInstall() and then you can (maybe ;)) call  _iosDevAdd() with a new name (see the diskboot stuff in drv_self_hide). But you'll have to work out the location of the pointers, only write is used in the tty stuff.
    Don't forget what the H stands for.

    *

    Offline srsa_4c

    • ******
    • 3133
  • Publish
    Re: How to prevent the writing of JPEGs
    « Reply #6 on: 21 / January / 2012, 11:23:42 »
    Followup.
    Starting with the late(r) VxWorks generation cameras, FileWriteTask got rewritten to be message-based. Unlike I stated before, hacking it is not actually "hard". It still looks similar to the old code.
    I've "created" another P.O.C. code, which can be seen here: http://chdk.wikia.com/wiki/User:Srsa_4c/SX100_FileWriteTask
    Since there seems to be no easy way to use a special filename like on VxWorks, I decided to replace references to Open(), Write(), Close() with fake code imitating "no error" or "everything's written". This approach seems to work. Faking an Open() failure with -1 as return value causes the camera to show a card error message (permanently) and further shooting is not possible.

    The message structure on the SX100 (DryOS r23) looks like this (word=32bits):
    offset, meaning
    0x00: msg number (this one is used in the main task loop)
    ...
    0x14: first data chunk's address (this is the Exif)
    0x18: first chunk length
    0x1c: 2nd data chunk's address (the main jpeg)
    0x20: 2nd chunk length
    0x24: 3rd chunk's address (observed: the first chunk's address)
    0x28: 3rd chunk length (observed: zero)
    0x2c: full filename starts here (A/DCIM/101CANON/IMG_0776.JPG)

    Structure on the A420 (it's specified by its address, 0x1ad70):
    offset, meaning
    0x04: first data chunk's address (this is the Exif)
    0x08: first chunk length
    0x0c: 2nd data chunk's address (the main jpeg)
    0x10: 2nd chunk length
    0x14: 3rd chunk's address (observed: the second chunk's address)
    0x18: 3rd chunk length (observed: zero)
    0x1c: full filename starts here


    In both cases, the room for filename is 32 bytes including the terminating zero char.

    At least on the A420, it's no longer possible to open a file (at least for writing) when FileWriteTask's open stage got executed. My dumping code got blocked, could not return, caused camera lockup. This is something similar to my experience with the movie record vs "dump memory".

     

    Related Topics