Messages

Now i'm getting stable 1280x536 (lovely 1:2.4 cinemascope ratio) at 18 fps, and with some effort and tricky twixtoring, i'm pretty sure i can shoot the whole short film entirely within the RAW workflow.

With all the fine detail, dynamic range, beautiful color reproduction and other flexibilities, we can now get a bunch of really shiny shots, guys.
Another color test: https://vimeo.com/67710667

Marvelous ! 

I got no love in "Share your videos" so I'll post it here as well.  I was trying to see if it's worth upscaling footage that's 1024x448 to 1080p or 1920x840 and here was my result.

The video you posted is 1920x840 (there are horizontal black bands in the upper and lower part): can you post a real 1920x1080 upscalig, just to taste it ? Many thanks ! 

Excuse my silly question, but: how to record raw in 1:1 crop mode, so no line skipping ? And how to record raw in no-crop mode (with line skipping??) ? Do "no crop mode" equals to line skipping entering into play ? many thanks ! 

I cannot understand the column :

Max resolution
1280x720
50/60fps

1280x720 no cropped, cropped, or what ?
In what way the fps are related to resolution here ? 

Another build with the help of Xaint

Congratulations to both ! Meanwhile, I updated the head post by adding also this release !
If I can be of help, let me know !

PS: do you will pull your memory improvements to the repo ? 

Am I the only fool here that discovered HDR RAW VIDEO is already enabled and operative, and it also works on 550D ? 

Done ! Thanks ! 

Guys, is there any location where all the builds for 550d are located? Ive searched around for it but it seems that it isnt located anywhere on separate topic. Is it possible to update the first post in this thread with latest builds?

Sure ! If mk11174 give me his permission, I will publish the links to his builds about 550D on the first post ! Good idea ! Thanks !

what is buffer size NxNN format ? For 550D there is a shoot_malloc of 75Mb, but where to find NxNN equivalent format ? 

@xaint: Many thanks! What is the source file dealing with waste mechanism ? And the one dealing with buffers sorting? At what line number is to insert the sorting code, now not present in the unified? I think we can add a #ifdef 550d for all this things and for my 1mb squeezing in exmem.c , what do you think?

- Modifying the "backup_size" (by upsizing or downsizing it), doesn't sort any effect at all.
- Changing the probe size from 4 to 2 and then to 1 (just to dig out more memory chunks), doesn't sort any effect at all.
- Forcing "size" to zero into the shoot_malloc allocation function, just to force it to allocate the maximum size, takes the camera to stack overflows and freezes that need to pull out the battery: no luck...

exmem.c - line around 147 -
hsuite = shoot_malloc_suite (max_size + backup_size - 8 * 1024 * 1024)
in this manner, the old version, we obtain 68Mb of shoot memory, good to serve as buffer for raw video (more memory, more resolution)
-----------------------------------------------------------------------------------------
hsuite = shoot_malloc_suite (max_size + backup_size - 1024 * 1024)
in this manner, the new and current version, we obtain 75Mb of shoot memory
-----------------------------------------------------------------------------------------
Our goal is to raise this shoot memory as high as possible, but the maximum I managed to obtain is :
hsuite = shoot_malloc_suite (max_size + backup_size)
in this manner, we can have 76Mb of shoot memory
Then, following this way... if you try  even a :
hsuite = shoot_malloc_suite (max_size + backup_size + 1024 * 1024)
the result is 0 of shoot memory !
-----------------------------------------------------------------------------------------

I have hitted a wall here... 

From a technical point of view, this thread is quite dead ! C'mon guys ! If you are trying something, no matter what are the results, share them with me so we can publish the efforts of all in order to progress ! 

This is where he got more memory.
https://bitbucket.org/OtherOnePercent/tragic-lantern-2.0/commits/60b04d7254cf8c5add9ee4a96822a1a7c81e1503

Good to know ! So... in order to squeeze more shoot_malloc memory, do we can play with this ? --> https://bitbucket.org/hudson/magic-lantern/commits/39d536e2b72c39b81855526fbd08f4281931ccbb     what do you think ?

@mk11174: the mod 1% did, after which we on 550D obtained more shoot_malloc memory, I think is that: https://bitbucket.org/OtherOnePercent/tragic-lantern-2.0/commits/a926b83dc3e933e42341baa3bd145ffd2aff7e81
So can we try to lower the new value, say put 0xc70100 instead of the preexistent 0xc60100, just to lower the autoexec.bin memory and so (hopefully) increase the shoot_malloc memory pool ? 

i personely can't read this out but i have a friend who maybe can... i write him and send him the benchmarks.iam waiting on his answer.

iam reading about sd host controllers...those this can be operation in many modes.so if the mode is set to sdxc highspeed the limit of the controller is 25mb/s thats theis the case on 550d i think.but there are to more modes one up to 50mb/s and one up to 105mb/s  for the sdxc standard...

Very good ! The point is that, if we can dig more info about the actual controller, perhaps we can hack it phisically someway, by hardware, like you say, without replacing it with a new one...

I've managed to find a couple of pics which I've been looking at:
http://www.hansonphotodesign.com/canon-550d-repair/hB61A13E#h1dfa5a1e <-- a 550D tear-down
http://www.ebay.com/itm/SD-BOARD-PCB-ASSY-FOR-CANON-EOS-550D-REBEL-T2i-NEW-/121119790044?pt=Digital_Camera_Accessories&hash=item1c334d53dc <-- ebay link to sd controller for 550D

It's a start ! 
Can you manage to read the writings on the main chip ? I cannot... ! It's important for us to identify it !

we can look at it and use octokoppler with this tools the hardware of the cam isn´t in danger.the 550d supports sdxc.the only true question is how fast is the busspeed 25 or 50..

Good idea, an optocoupler can do the trick, even if it adds bulk and complexity on the Whole thing... we should however try to get as info as possible on the signals by monitoring them, before attempting any intervention...

if we look on the memory benchmark the bus have to be more than 20. or iam wrong?

Yes: on the uncachable memory benchmarks, my 550D maxes out to about 66Mb/sec ... so it is correct to think that the cpu bus speed is at least 3 times faster than the SD card controller ! If this value is not from a DMA channel, this is a true bus channel 

Let me know what are you tinking about this possible discovery of mine : There are clues that, in order to make room for the raw_video_rec module, we used the shoot_malloc memory to put there the ML code, so shrinking it, so we cannot have more shoot_malloc memory anymore... look at this : http://www.magiclantern.fm/forum/index.php?topic=5071.0

The base idea to swap the current controller with a faster one is good and feasible.

But we must face with the processor bus speed, and see if this bus speed is enough for the new speed of the new controller.

The BUS is the "highway" where all the peripheral signals go and come to and from the processor. If the speed of this bus is equal to 20mb/sec (example for the 550D, whose SD controller is limited by this speed), then there is no point to improve the SD controller speed.

If then we try to overclock the bus speed, then the processor may lose some data from the bus, so the bus and processor speed are tigthly correlated. You can overclock the processor, but then it could behave like drunk and screw up all the system, on a random base, and it can overheat and burn on the long term. So, we can only see if the bus speed can let us to improve the SD controller speed.

No, not yet, I dont know how to add to that, I just added it to build it myself for now till someone that knows how adds it.

If you try to build now from bitbucket and use Raw it will not work because of the Seek address not there yet.

line: 85
NSTUB( 0xFF1C691C, FIO_SeekFile)

If you know how to get it on there or pull it or whatever its called, lol

I dunno who made this, but your modification is already merged in the bitbucket unified ! Great !

I have, however, some questions, just to clarify things better, to me and to others that may come to help :

[1] Do there are Others stubs to search for (not for this specific memory problem, but for other purposes... just to know) ?

[2] Do someone knows what are the source files (and where are they located) that are involved into enabling sRAW feature and at what lines, inside them ?

@xaint and @mk11174 : do one of you already made a pull request about the new and last (and only one...  ) modification ?   
Do the old hack mods pull requests where already deleted or reversed ?

[Only one very important pray]

@xaint and @mk11174 : Very good work, boys !

Only one very important pray : do not erase your repos and modifications ! Don't think they are not useful because another programmer did it yet the same ! Keep all your work, because it may be useful to dig into the differences (if there are any) between your sources and the Others sources, in the case something wrong or bugs should arise in the next or long future !

Many thanks to all of you !! 

If the changes what i've made are working, how can i push it to the main repo? Only the three affected files, without having to spoil something? Pull request?)
Thanks in advance

Have you checked all the hints in the head post and the last I written to mk11174, so to be in phase with the mods ?  They are 100% certified from... 1% ! 

If the changes what i've made are working, how can i push it to the main repo? Only the three affected files, without having to spoil something? Pull request?)
Thanks in advance

hg commit
then PUSH to your repo (if you have made a repo online with bitbucket)
then make a pull request from your repo to Hudson repo (the official one)