Raw buffers - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1]   Go Down

Raw buffers

  • 8 Replies
  • 6398 Views
*

Offline RaduP

  • *****
  • 926
Raw buffers
« on: 03 / October / 2009, 03:29:19 »
Advertisements
I was wondering, why are there two raw buffers? Does the camera use both, arbitrary?

And are they mapped in the 0-32MB memory as well, or are they some special RAM that is only found at some unstandard location?

And one last question: How exactly do you find them both? I was able to find one, but no idea how to find the other.
In the SX10 port, there is this code (which is similar to other ports)
Code: [Select]
char *hook_raw_image_addr()
{
return (char*) (*(int*)(0x55CC+0x18) ? 0x424F1948 : 0x40F65B18);
}

So why that table at 55cc? And are both pointers somewhere in that table?
Looking at my camera memory dump, I found what I believe to be one of the RAW buffers for my camera (0x418B0560), at location 0x43d4, and right next to it, at 0x43d8.
Logged
*

Offline reyalp

  • ******
  • 14134
Re: Raw buffers
« Reply #1 on: 03 / October / 2009, 04:15:18 »
 
Quote from: RaduP on 03 / October / 2009, 03:29:19
I was wondering, why are there two raw buffers? Does the camera use both, arbitrary?
Only some cameras use multiple raw buffers. Why ? Ask Canon. Probably allows them to pipeline more.
Quote
And are they mapped in the 0-32MB memory as well, or are they some special RAM that is only found at some unstandard location?
They are in the same memory, but are generally accessed through uncached addresses. Some cameras have more than 32mb, BTW. You can figure out how much (and where the cached/uncached addresses are) from the CP15 setup code at the very start of the dump. If I'm not mistaken, the sd980 as 64mb.

Quote
And one last question: How exactly do you find them both? I was able to find one, but no idea how to find the other.
In the SX10 port, there is this code (which is similar to other ports)
Code: [Select]
char *hook_raw_image_addr()
{
return (char*) (*(int*)(0x55CC+0x18) ? 0x424F1948 : 0x40F65B18);
}

So why that table at 55cc? And are both pointers somewhere in that table?
What we access is just a flag that tells which address is used. AFAIK they do not get copied to  RAM, but they might. On the SD990, I found the second one from a structure in ROM, based on a similar structure in other cameras.
Code: [Select]
char *hook_raw_image_addr()
{
//    return (char*)0x40EBAFA0; // seach on CRAW BUF
  return (char*) (*(int*)(0x5520 + 0x18)? 0x42CFB780 : 0x40EBAFA0);
// similar to a560, searched for first raw address in a table with others, get variable from functions that use table
}
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Raw buffers
« Reply #2 on: 03 / October / 2009, 13:42:17 »
Thanks for the reply.
I am pretty sure my camera only has 32MB, when I tried to dump 64mb it crashed.
The size of my raw buffer is around 16MB, so I guess I only have 1 raw buffer then.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Raw buffers
« Reply #3 on: 03 / October / 2009, 14:00:30 »
One other thing, probably you won't like my idea, but I think that hooking capt_seq_hook_raw_here is a pain in the [admin: avoid swearing please], and we are at the mercy of Canon not changing much stuff in the firmware. On my SD980, there were quite a few differences from SX10.

Anyway, capt_seq_hook_raw_here doesn't do much at all, except for telling our main thread that hey, there is data in the raw buffer, you can save it. So why not, instead, have the main thread check the raw buffer for changes? We can select a few 'pixels' from the raw buffer, maybe 10-20, and monitor them. Once a raw file is saved, those pixels can be reset to some random values, and if they change again it means we have new data. This method is much more simple, should be pretty reliable, and resilient to changes in the firmware. It is also compatible with all the cameras, if we take into account the raw sizes.
Logged
*

Offline reyalp

  • ******
  • 14134
Re: Raw buffers
« Reply #4 on: 03 / October / 2009, 17:46:50 »
Quote from: RaduP on 03 / October / 2009, 13:42:17
Thanks for the reply.
I am pretty sure my camera only has 32MB.
Code: [Select]
ROM:FF810040                 MOV     R0, #0x33
ROM:FF810044                 MCR     p15, 0, R0,c6,c2
ROM:FF810048                 MOV     R0, #0x40000033
ROM:FF81004C                 MCR     p15, 0, R0,c6,c3
Regions 2 and 3 are 64 megs, starting at address 0 and address 0x40000000 respectively. But maybe Canon screwed up the MPU settings ?

CRAW BUF 0x421E1120 (via sub_FFB0E650)
0x40000000 is the uncached bit, so the actual address is 0x21E1120 or 35524896 dec. Notice that this is starts over 32MB.

Quote from: RaduP on 03 / October / 2009, 14:00:30
Once a raw file is saved, those pixels can be reset to some random values, and if they change again it means we have new data. This method is much more simple, should be pretty reliable, and resilient to changes in the firmware. It is also compatible with all the cameras, if we take into account the raw sizes.
1) Other things need to be done in capt_seq_task.
2) you are assuming that the memory used for the raw buffer is never used for anything else, and only changes once in capture process.
3) you are assuming that spytask will actually run at a time where it can intercept this. Note that the raw hook makes capt_seq stall until raw saving is done.

So no, I don't like your idea.
Logged
Don't forget what the H stands for.
*

Offline fudgey

  • *****
  • 1705
  • a570is
Re: Raw buffers
« Reply #5 on: 04 / October / 2009, 11:12:14 »
It would be great if RAW could be saved in the background (in normal interactive shooting, while getting ready for the next shot or looking at the previous photo in PLAY mode, and if the camera uses multiple RAW buffers, maybe RAW burst speed could be increased).

Of course this could only work if the RAW buffer doesn't change until the next shot, but if in certain conditions or certain cameras it doesn't, I'd like that option. I don't know how much CPU effort RAW saving needs and how it would affect the camera, but from experience I do know reading images via USB from the SD card while shooting seems to work fine.
Logged
*

Offline RaduP

  • *****
  • 926
Re: Raw buffers
« Reply #6 on: 04 / October / 2009, 14:04:13 »
Well, I can't say I looked at how much, if any, the raw buffer changes except for when shooting, but I don't see why it would change if no new image is available. Unless if the camera does part of the post processing using the raw buffer, that is.
Logged
*

Offline reyalp

  • ******
  • 14134
Re: Raw buffers
« Reply #7 on: 04 / October / 2009, 17:28:53 »
Quote from: RaduP on 04 / October / 2009, 14:04:13
Unless if the camera does part of the post processing using the raw buffer, that is.
Or the camera uses it for something else in between shots. Or it's tied to the sensor in such a way that it has garbage at certain points.

These would all be interesting things to investigate, but it will be a lot more work than just doing your raw hook like every other camera.
Logged
Don't forget what the H stands for.
*

Offline RaduP

  • *****
  • 926
Re: Raw buffers
« Reply #8 on: 04 / October / 2009, 17:42:33 »
Well, when I am done with the port, i will be very happy to investigate, because I think it could be used for a lot of nice things, if the camera doesn't trash it in between shots.
Logged
Pages: [1]   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal