Messages

If it happens without ML it may be an issue with the display sensor. Try to clean it properly

Yeah, Im sure too that must be the display sensor.. Nothing else can cause the fail.

thank you guys i fiind the solution must turn off dual ISO

You made my day man..

i found a temporary solution for that problem. i just reboot my camera like 10times and 1/10 i got a clean boot with no errors while dual iso is active. but it is annoying as hell. i beg for a permanent solution. please.

Restarting the camera 10 times isn't a solution. (Despite the fact that I restarted my camera for like 20 times but the error was still there... ). And everything is the same when you boot up the camera, restart 10 times or 100 times. It must be something else that has fixed the issue for you..

i have this issue on my display i have this error ISOless PH err(2) what shold i do

I just cleared all my camera settings and it got fixed. However I haven't identified the main cause of the problem so far.

Not r a coder myself but wouldn't the # before define make it a comment and be ignored?

No. Not in C.  For example we do #include, which includes a file. # indicates a comment in bash scripts usually.

http://www.cprogramming.com/reference/preprocessor/define.html

Nanomad, what's the procedure I should follow to get the silent_pic_get_name function to be defined?
I decided to do some raw test using the don't click me option (which is what you guys use for debugging I think).

Code Select Expand

static void run_raw_test()
{
    /* Run RAW test to determine the best RAW_TYPE on 650D */
    for (int type = 0; type < 100; type++)
    {
        /* from lv_af_raw -> lv_set_raw_type(arg0 ? 4 : 7) -> MEM(0x2D168) = a bunch of values, default 34 */
        /* RAW value address for 650D is 0x350B4 */
        MEM(0x350B4) = type;
       
        /* this enables a LiveView debug flag that gives us 14-bit RAW data. Cool! */
        raw_lv_request();
        msleep(50);
       
        /* after filling one frame, disable the flag so we can dump the data without tearing */
        raw_lv_release();
        msleep(50);

        /* update raw geometry, autodetect black/white levels etc */
        raw_update_params();

        /* save it to card */
        char* fn = silent_pic_get_name();
        bmp_printf(FONT_MED, 0, 60, "Saving raw type %d", type);
        save_dng(fn);
    }
}

I got the code from a post by a1ex.

This is what I did until now:
1. In the src/debug.c I wrote my custom function which does the test (captures dngs and saves to sd using the silent_pic_get_name function).
2. I changed the function that the Don't Click Me option calls to the custom function I wrote.
3. In the features.h file in the 650D, I defined two options: #define FEATURE_SILENT_PIC and #define FEATURE_SILENT_PIC_RAW which is what I think causes the function to be defined....

But until now, all I get is this when compiling:

Code Select Expand

debug.o: In function `run_raw_test':
debug.c:(.text+0xb90): undefined reference to `silent_pic_get_name'
state-object.o: In function `stateobj_lv_spy':
state-object.c:(.text+0x150): undefined reference to `silent_pic_preview'
state-object.c:(.text+0x1d0): undefined reference to `silent_pic_raw_vsync'

Got any ideas?

here's whats on it
DCIM
magiclantern-v2.3.NEXT.2013Aug03.650D104
650D.104.installer.fir
autoexec.bin
autoexec.bin.cpgz
INSTALL.pdf
ML
UserGuide.pdf
magiclantern-v2.3.NEXT.2013Aug03.650D104.zip
MISC

Just to be sure, check your firmware version.. Are you already on 1.0.4? If you are not, you should update to 1.0.4 first.

[B]

The card is not the limitation (if you get a 45MB/s card).  The hardware in the camera is what runs at 100 MHz and cannot be changed (entirely new level of hacking, start your own forum).  The bus sends 4 bits per clock giving a theoretical max of 50MB/s.  IRL we are seeing ~40MB/s on testing.  Not trying to be a jerk with the bold but incorrect capitalization when taking about such things might get you bit.

May not want to send him back there undirected.  There was much misinformation on that thread as well.

Thx for the reply I'm aware of the difference. I was just being lazy to make the letters capital. Sorry.
I know that's the camera hardware which runs at 100 Mhz and not the card. My point was that if even the camera supports higher transfer rates, your card should still support higher rates.  Anyway sorry for the misinformation.

So concluding from your information, the only way to support higher transfer rates is to overclock the camera hardware. right?

I would test the overclocking if I had a useless camera in my hands and I didn't mind if it broke. But I really test magic lantern on my primary camera which I use for daily stuff and I'm worried. If it breaks, I'm dead :p

I found the comment below in another forum.  It implies only 560.  So are you guys really getting 1080 x 720?

vitos1k
Just arrived
*
Posts: 6

RAW on 650D / 700D?
« Reply #10 on: June 01, 2013, 04:16:54 PM »
Quote
1280x560 is maximum i could get on my 650D with UHS-I card. It seems that controller is limited to 30-40mb/s which is poor
but 1280x560 looks great, even upscaled !

You guys are saying that when you use the UHS-I cards in your 650D, you can't get above 30-40mb/s ? Because as I researched, I found out that UHS-I UHS104 cards can record up to 104 mb/s with 208 Mhz clock frequency, but only 50 mb/s with 100 Mhz frequency.

Maybe you don't have UHS104 cards and are using slow UHS-I cards?

See here: https://en.wikipedia.org/wiki/Secure_Digital#UHS_Speed_Class

Could you explain to me how this is different from just hooking up your camera now to your PC and browsing the folders on the SD card through the computer?

Yes Many Image import softwares (like Adobe Bridge, Image Capture (Mac), etc.) won't import the RAW videos (because the format is unknown for them) and you can't change other extra files you might have (ML files for example). So you need a card reader to be able to get the RAW videos you shoot or update ML. I think it will be cool to be able to directly access SD from the USB Cable.

The binary is relocated in memory at boot, but we need to read config and such from the SD card. Also, canon needs the SD to save photos..

I know that, but we can just stop that functionality for a while, mount the sd to the usb, let the use transfer photos and what he wants to do and then we can remount it on camera and continue the operation. Just like the approach that Android takes.

Hey nanomad and other developers!
I have a idea for a new feature. Can't we have USB mounting functionality? I mean to be able to access the SD through the usb cable. I know ML loads from SD but if we able to achieve that, it will be a great help to people who do not have a reader handy!

I actually can try to implement the feature (I am an embedded C developer), but the thing is I'm not familiar with the ML code and don't know if it's possible or not (Because the thing I said in above.).

The question is when ML loads, does it need SD card to continue operating or it has just been already copied in the memory?

With none-eabi (which is supported in newer versions of gcc) I get this error:

Code Select Expand

stubs.o has EABI version 5, but target magiclantern has EABI version 0
But with elf (which is obsolete since 4.7.3), gcc complains about VFP.

What do you mean by ubuntu toolchain?

EDIT:
And now with linaro's gcc 4.7.4, I get :

Code Select Expand

[ LD       ]   magiclantern
/home/minlite/toolchain/arm-elf/lib/gcc/arm-elf/4.7.4/../../../../arm-elf/bin/ld: cannot find -lm
collect2: error: ld returned 1 exit status
make: *** [magiclantern] Error 1

Finally I fixed the error.
I deleted the magic-lantern code and cloned it again to my system. And used the same gcc as in Makefile.user.default file. Suddenly it started building just fine.

I guess maybe some of the last commits have solved my problem. It is still strange to me. The thing I spotted is that, when I couldn't build, the GCC_VERSION constant in the Makefile.user.default file was being set to plain 4.7.3, and I was setting it to any version I used.
But the new file uses a small dash(-) in the beginning. (It is defined as -4.7.3). That's why I'm sure it was the Makefile.user.default causing the problem.

Anyway it is solved now, and I have the autoexec.bin being built

Can someone tell me what the settings for Macboot are?
I installed ML following the instructions and I can see the ML menu but when trying to shot, the default Canon options appear instead.

Even when in the ML Menu I can see the exposure meter overlapping the ML menu options.

Somebody else has the same issue?

Thanks
Guille

If you see the ML menus, then you have enabled the bootflag right and you have ML running As far as I know, you don't have to do anything with Macboot with newer versions of ML. If you just update with the .fir inside your SD card, then it will automatically enable the bootflag.

For the exposure meter, you are in the LiveView probably. It's a bug in the ML. You should hit the info button until the canon menus go and you only see ML stuff. any if you press Trash in that mode, the exposure meter won't overlap the ML menu.

Post the build logs. Ubuntu's toolchain is good. That's what I use every single day. You need to create a Makefile.user with the correct paths and GCC versions though.

With none-eabi (which is supported in newer versions of gcc) I get this error:

Code Select Expand

stubs.o has EABI version 5, but target magiclantern has EABI version 0
But with elf (which is obsolete since 4.7.3), gcc complains about VFP.

What do you mean by ubuntu toolchain?

EDIT:
And now with linaro's gcc 4.7.4, I get :

Code Select Expand

[ LD       ]   magiclantern
/home/minlite/toolchain/arm-elf/lib/gcc/arm-elf/4.7.4/../../../../arm-elf/bin/ld: cannot find -lm
collect2: error: ld returned 1 exit status
make: *** [magiclantern] Error 1

I confirm that the pink dots are gone!! (Special thanks to theunkn0wn). And as far as I've tested, there are no green dots in my 650D and raw.

However, I still experience issues compiling the ML. As far as I've searches, all the compile guides out there are out-dated and unusable.

I tried to build on all GCC versions (from 4.6.2 to 4.8.1) with both the none-eabi and elf targets, but none of them could build the ML successfully.

Can please someone who can build now (like satriani or theunkn0wn), provide us with their gcc binaries?

Thanks

I am professional cameraman at least 15 years (and you?) , and saying - you footage is rubbish... dropped frames ets)
RAW video is only for advanced color correction and grading, nothing more nothing less, not increasing quality and dynamic range that cheapest camera.
BTW - there is no way to record long, usefull, non dropped frames FullHD RAW on 650D due flash card i/o module - you just wasting you time

I repeat again. That was just a test footage. The purpose is to see if there are dropped frames. How can you complain about being dropped frames. :|
I don't see any reason, that I should reply to your attempt to show off. I don't care if you are a professional cameraman or whatever. I just judge you with what you post here.
And attempting to solve things and getting things better is not wasting time. The reason that today you can use Magic Lantern, is that the guys have "wasted their times" solving problems and developing great products.

And when it comes to computers, there is nothing absolutely impossible. You will always find a way of doing it.
Just to prove you are wrong, here is an idea to overcome the problem that just hit my mind. You can connect two cards in a RAID-0 like , hardware level array, which will double the performance.
For example if you have two 8 GB 30 MB/s cards, you can get one 8 GB 60 MB/s card out of the two cards.
See, it's not impossible. You just have to think a little.

Thanks but I was referring to the fact that minlite13 specifically said he didn't use that tool, upon further inspection of his video (ie in 1080p ) you can still see the pink dots too.

Yes. I didn't use any PickDotRemoval tool. Because of some reasons.

1. The PinkDotRemoval Java application is calibrated to be used with the 1280x720 resolution. I only had a SanDisk Extreme 30mb/s card around so I couldn't record in that resolution. I recorded in 960x540 instead, so basically, the PinkDotRemoval tool wouldn't work.

2. And I tested RawTherapee app on my Mac too. But I wasn't comfortable with using it's settings. Although the hot/dead pixel removal option worked very well, the main problem was that I wanted to use Adobe CameraRaw to process the DNG files, but RawTherapee couldn't reproduce fixed DNG files.

So I couldn't use any pink dot removal tool. After processing with Adobe CameraRaw, the dots weren't visible that much, but if you see in 1080p. you can see that they are still there.

Anyways sorry for the confusion.

I don't get what are you trying to say by "Absolutely Useless feature".  If it's a feature then it's not useless. Despite the fact that, the whole of us have agreed that it's a great feature and Magic Lantern team is including it in their builds.

I just posted this early test video here to sum up what is done until here on the development of the feature, because all the test videos were recorded using the old 1.0.1 version.

And I assume this is nearly a dev topic. So please don't spam by saying thing like "This feature is useless", "What is it? What is that?" ,..

I have recorded a one minute raw footage with the 650D using ML and I felt like I should share it here.. Because you guys are doing an amazing work, bringing a whole new life to our DSLRs

Plus I would be happy to see your opinion on the video. Thanks.