500d development - page 16 - DSLR Hack development - CHDK Forum

500d development

  • 2487 Replies
  • 898123 Views
*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: 500d development
« Reply #150 on: 13 / February / 2011, 03:38:40 »
Advertisements
Squibberling: my best guess is that is caused by too much static memory used by ML. Get rid of big static vectors like the one from waveform (not sure if you still have them in the code) and compile with -Os instead of -O3.

720:624: nice find, strange resolution. Is it 1:1 aspect ratio or is distorted? If it's 1:1, that may mean 500D's sensor is almost square...?!?!?!

Solid blue line can be due to code reading past the end of the buffer (where there's no more image data).


*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: 500d development
« Reply #151 on: 13 / February / 2011, 03:42:48 »
RoaldFre: I see heavy posterizing in your square image, which makes me to think it may be a version of the image converted to bitmap overlay's palette (or something like this). The other components may be some image data at lower resolutions.

Yes, the format is YUV 422, see 422-jpg.py for how to fully decode it.
« Last Edit: 13 / February / 2011, 03:44:33 by a1ex »

*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: 500d development
« Reply #152 on: 13 / February / 2011, 03:43:41 »
Alins: what changeset from 550D did you use? I'd like to make a diff to see only your changes.
« Last Edit: 13 / February / 2011, 03:56:50 by a1ex »

Re: 500d development
« Reply #153 on: 13 / February / 2011, 06:52:48 »
[...]
You may find the smaller 720x480 buffer (for which you don't have to do any scaling) in the log file (look for "setImageVramParameter" or something like that). There are 3 of them (but you only need one; if you have them all, you will just get more fps).

./force-lv.LOGp:2880: 9821: 8627.652 [DISP] SetImageVramParameter pAddress=40d07800 pFlipCBR=0
./force-lv.LOGp:2895: 9840: 8666.812 [DISP] SetImageVramParameter pAddress=4c233800 pFlipCBR=0
./force-lv.LOGp:2908: 9853: 8707.732 [DISP] SetImageVramParameter pAddress=4f11d800 pFlipCBR=0

I couldn't find any reference in the logs yet. I've tried opening up live-view, movie mode, actually recording a movie, etc. What event should trigger this log dump? (Maybe Alins has more luck?)

As for the VRAM buffers: there were still some other parts that seemed to hold images, I'll hunt them down now (well, unless someone gets the values from the log, which would be more easy :P). I'll have a quick look in other segments too after that (right now I've only stuck to 0x4xxxxxx).

[edit]
Regarding the posterizing: I've noticed that too. For completeness, I've also uploaded the images from the other buffers, see my previous post. You can clearly see the change in aspect ratio, and there is also some cropping between the two buffers.

[edit2]
I've scanned through the entire 0x4xxxxxxx range and I've found a third 630*624 image, as well as a 320*240 one.
I also had dumps for the 0x1xxxxxxx range, but that only seems to give random, constantly changing garbage.

[edit3] just scanned 0x5xxxxxxx: all constantly-changing garbage. There does seem to be some interesting bits in the 0x3xxxxxxx range, though -- examening that now.
« Last Edit: 13 / February / 2011, 09:49:48 by RoaldFre »


Re: 500d development
« Reply #154 on: 13 / February / 2011, 09:49:29 »
In the 0x3xxxxxxx range:

0x31B07800: 720*424, pitch=1440, odd.png: http://i.imgur.com/J6TIw.png
[EDIT] I overlooked this one in segment 4, so it seems. This one can be found at 0x41B07800 as well.


I think I just stumbled across the memory ML uses to write to the screen (once again: note that I just started messing with the dumped data before looking through the ML code, so I don't know which memory sections already ML uses itself)
The way I find these memory chunks is by making two memory dumps, one after the other, and using imp.py to dump images of the difference between those dumps. This is the command I use to sweep through a segment:

x=0x3000000; y=0x1000000; p=1440; s=readseg("3.1.bin", x, y); t=readseg("3.2.bin",x,y); imgseq(array(s)-array(t),p)

always increasing x by 0x10000000. The file 3.{1,2}.bin are two dumps of segment 3. That particular command gave the image http://i.imgur.com/3Ab7w.png as odd.png. Notice that there are two (difference of) images here and that the pitch is correct at 1440 (so a horizontal resolution of 720). Also notice the "Dump segments1" bitmap right above the first image -- that's a piece from the ML menu.
A regular dump (odd.png) looks like http://i.imgur.com/3Ab7w.png (so this is not the difference of two memory regions)

The two images found there are located at:
0x33738800: 720*424, pitch=1440, odd.png: http://i.imgur.com/TLeRl.png
0x33B48800: 720*424, pitch=1440, odd.png: http://i.imgur.com/EoSS4.png
[EDIT] These are also at 0x43738800 and 0x43B48800, overlooked them in segment 4.

So that's three buffers of 720*424


Posterized, side-by-side buffer:
0x33F51000: 630*624, pitch=630, full.png: http://i.imgur.com/o8NcZ.png
[edit] also in segment 4

Small, wrong endianness buffer:
0x33FD6420: 320*240, pitch=240, full.png: http://i.imgur.com/arQyU.png
[edit] also in segment 4

Third and fourth(?) focus peaking buffer found -- maybe just a copy because of similar address?: [edit -- you guessed it, it's from segment 4]
0x34000080: 928*616, pitch=1856, odd.png: http://i.imgur.com/WROse.png
0x36000080: 928*616, pitch=1856, odd.png: http://i.imgur.com/p9O0G.png


Another 720*624, probably a copy form segment 4 as well:
0x3FCB6C00: 720*624, pitch=1440, odd: http://i.imgur.com/4JQJM.png

Two more posterized side-by-side buffers, probably a copy of segment 4:
0x3FD97C00: 630*624, pitch=630, full: http://i.imgur.com/mLQZS.png
0x3FE1B000: 630*624, pitch=630, full: http://i.imgur.com/SgZ0c.png

And that's all for the 0x3xxxxxxx segment, which seems to hold the exact same things as segment 4.
I'll be a bit short on time the next weeks (college has started again here), but I'll try to get the other sections done as well asap.
« Last Edit: 13 / February / 2011, 11:56:51 by RoaldFre »

Re: 500d development
« Reply #155 on: 13 / February / 2011, 11:20:38 »
But the question is:
Will it have 1080/24fps? If not: Why not?
Haven't you seen that 500D records 1088/20?

Re: 500d development
« Reply #156 on: 13 / February / 2011, 11:21:50 »
First of all, great work you guys! I've been waiting for this for 2 years!
I'm pretty much code-retarded, and so am wondering if the memory leak which occurs with the intervalometer will be addressed with the next alpha update.

*

alins

Re: 500d development
« Reply #157 on: 13 / February / 2011, 15:12:37 »
I couldn't find any reference in the logs yet.

here's a log file that i just generated. i can see calls to SetImageVramParameter but no pAddress. Do i need to enable something ?.the way i got this is by dumping the log after recording a movie. dumping _while_ recording movie seems to cause error 70. Also from alex comment i see he's pointing to "force-lv.LOG" log file. Are you using something else to dump the LV data Alex, i mean something other than a simple "dump dmlog"

Alex: i will submit my changes to bitbucket soon, hope this helps. I ported code from 550d from different changesets, i don't remember which ones..sorry. About the intervalometer problem: for 500d i haven't found the address for AllocateMemory so i changed the code to use malloc everywhere, just so we can move forward. Could this cause the problem?


*

Offline a1ex

  • *****
  • 671
  • ML dev
Re: 500d development
« Reply #158 on: 13 / February / 2011, 16:34:49 »
If malloc is able to allocate the zebra buffer, probably that's the one you are looking for :)

Cameras are different, I've just showed you what happened on mine. The file name is one of my logs which happened to contain those lines. I keep them archived and search through all of them to discover new stuff.

I didn't use other tools for dumping image data.

Samsongas: if you know how to do this, you are invited to send a patch ;)

Re: 500d development
« Reply #159 on: 13 / February / 2011, 18:51:43 »
Samsongas: if you know how to do this, you are invited to send a patch ;)

I know I'm invited. I really apreciate what are you doing and I wish I had the time to study te codes. I feel really helpless but if you finally end there is no dubt in the fact that I'm going to donate.
Just asking if it would be possible.

 

Related Topics