Messages

can the pixel mode be set for create/capture test image? I see 16bit mode is only used for faCalculateVProjection

Which path constructs LV raw? maybe cache hacking there would be the simplest way to achieve 12 or 10 bit for video without re inventing the wheel.

Its not strange, the toggle is on the other proc (which I enabled), the sense is also on the other proc (which I can't access). So it works if started manually, just its not in the nightly.

no, magic/tragic record times should be the same on 7D.

GD :off 23.976
2:00 MLV/Snd
2:40 MLV
4:09 Raw Rec

Both versions should have identical speeds with SRM and the same edmacs being used.

There are questions on 7D concerning edmac flags, break after xGB (this went away and returned), some irregularity in write speed on mlv, not present in raw_rec. Finally looks like we're approaching 50D continuous recording.

It could be fast enough for real time if a smaller frame takes less than 41.66ms to convert.

The twoadd might convert 14 to 12?  TWOADD_SETUP_14_12

He wanted his cake and to eat it too. It would only help his paid app, not anyone else. If he wanted to help he could have written hot pixel/banding code that works for more than 5DIII and then released that as a library or hell even in the paid app.

This is why people get impatient with the open source movement. It's like dealing with a bunch of schoolchildren.

This is why developers get pissed at profiteers who take someone else's code/ideas and then try sell them for themselves, in many cases adding nothing to the original and then getting pissy at the original creators. Its kinda endemic on android: http://www.eurogamer.net/articles/2014-02-14-ripping-off-flappy-bird-the-murky-world-of-app-cloning

It doesn't play nice with live view on digic V. Digic IV was better. I don't think its the module, just the canon engine if its used for defect correction, probably why it didn't work for live preview.

We already had the preview but parts of them would get burnt into the cr2.

You could try a couple of buffer graphs, MLV still makes them I think and saves a pic.

FA_DefectsMergeTestImage  but no info on parameters or debug message.

Looks like its relatively easy to do in camera dark frame subtraction... at least on silent pics.

FA_SubtractTestImage pSrc=%#lx, pDark=%#lx, pDest=%#lx",0

Doubt it for mlv/raw, esp since the live preview doesn't want to work with Furikake.

Remove hot pixels with the defect correction engine?

FA_DefectsTestImage pSrc=%#lx, pDest=%#lx",0

wonder how fast this one is.

Problem with using edmac memcpy to test is that its a fixed size and testing one thing, ram -> ram. MLV will have different amounts of data depending on resolution. Also it might vary somewhere here edmac -> memory -> card. Should run the test on 7D and see if it comes up higher on the memcpy test.

I guess next thing to try is to feed it hard coded YUV422_LV_BUFFER_DISPLAY_ADDR and see if does the preview.

Nope, no method lets it work in real time

Best I get is a single frozen frame. At least on 6D. I can try on 7D too but I suspect results will be the same.

6D 113 FF5ABF84 ProcessPathForFurikake
7D 203 FF3A325C ProcessPathForFurikake 

6D module loaded, 5x broken, 10x ok. DNG playback looks like 5x. Sometimes crashes after playing a file. Playback def faster.
7D module loaded, 5x ok, 10x ok, recording ok. Playback a bit faster. Taking a full silent pic output is black + hang, playback is black + hang.

Live previews do not work on either camera, neither color nor BW. I'm guessing MLV preview set to auto was entering this mode for 5X.

Something to do with defect correction processing? Maybe thats why zoom is broken? What else can it do?

Its funny because he could have released the source code freely and I bet 90% of his user base would not compile it. Just had to ask that nobody else post binaries.

If one converts RAW or MLV files with RAWMagic that don't suffer from the vertical stripes issue, no GPL code is employed whatsoever (external binary or otherwise) since vertical stripes correction isn't needed

Are you for real? You want to steal the vertical stripe correction which only kinda sorta works on 5DIII, cry about GPL licensing and then not fix the multiple banding/pattern noise/hot pixel issues across cameras while charging $30? Some better batching on MLrawViewer would end this in a heartbeat.

It doesn't really work on this camera (nor 7D), you can keep trying tho:

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d/src/bcfa214064995813a2f4172dddc3fcc60b87af66/src/raw.c?at=unified

Its my magic lantern fork mainly for 6D/EOSM/50D/7D and sometimes 600D. So tragic lantern, ml vs tl, etc.

Regardless though, one of 2 things is happening.

1. Your card isn't bootable. No bin runs.
2. Your camera never had ML/TL/chocolate rain and the installer is again broken by changes to fonts or something else.

So to fix #1 make SURE the card is bootable by EOScard. It should keep the bootable flags when you close/restart the program and remove the card.
To fix #2, download/extract a whatever lantern zip from around 2014-03-17, which is when the installer was made and also be sure the canon 113 firmware file isn't in the root of the card.

After you successfully boot flag the camera you can replace the support files (ie ML folder) with whatever you chose.

Card bootable -> disk bootable
Camera bootable -> boot alternate device/boot order

to put it in desktop computer terms.

There's no difference in ml/tl bootflag setting. There is only 1 in camera boot flag. To swap versions you just copy the files from the zip to the card. The card still has to be bootable for ANY autoexec.bin to run.

If this doesn't work: Format card again, download Canon's firmware version 1.1.3 from here:

Reinstalling 1.1.3 doesn't remove the boot flag. Formatting the card will unmark it as bootable and then nothing will run, fix this with EOScard (overwrite anything it auto downloads with whatever you want). With luck this is what happened and you don't need to mess with the fir ever again.

none of these other cameras flip fps, ie 5D3 could use fps override without doing it from EVF state.

I don't really want to argue about this as its not helping anyone. My sole reason for having a separate code base was that certain things just don't get accepted into the main repository or are deemed as too something, be it "dangerous", useless, not spaced properly, not important enough, etc.

The kickoff was movie remap on 600D. It was the only camera I had, the modes are on opposite sides of the dial. The feature had been working for a long while and then it caused problems on 60D and was pulled from 600D. It really killed usability. People complained but yeah, what can they do. So I thought since I'm already compiling this to get the latest changes why don't I just put it back, I'm willing to take the risk. I posted an autoexec in the downloads of the repo in case anyone wanted to use it for themselves. Nobody really cared.

Then I wanted audio controls and better video so I worked on those, from knowing nothing to knowing a little. Tested and tried, got some help and we got something going. Still nobody cared so much. I saw other people try to code things, they languished in the pull requests section but I wanted to try it that day so I pulled the changes in and tried them. Sometimes it had to be done by hand + fixed. It was pretty addicting and I learned a bunch on coding and reverse engineering. I was having fun.

So at least a year or so goes by and there are many refactors, yada yada. Things become incompatible, there are major changes. Manual merges I have to spend hours on, etc. I figure its my problem oh well. I'm not the best coder or the neatest. I try to help reverse engineer and figure things out. Sometimes it gets into the main repo, sometimes not. More people are using the 600D builds. The video stuff is deemed useless/dangerous/etc.

Then I end up with a few more camera bodies. I see how hard it is to support this many. I find many things that just needed a little fixing and share my results. Some of it is ported back, some of it is not. At this point I don't know how to work pull requests yet so coutts ports the 6D stuff back to main and the nightly works. Some stuff gets turned off but hey, main is supposed to be stable. All is well, right?

Guess not, as more people just go for my downloads this drama develops. A1ex views it as competition and as his time isn't infinite doesn't want to go through and pull out the good code, or use stuff the doesn't agree with (esp. blindly). I'm having trouble at this point maintaining + testing 5 cameras, it takes a long time. I can only shoot with one at a time, I'm a shitty coder.  Users come in with questions and unreasonable demands about ML and TL and now people are downloading my builds instead of his so its even more of a thankless job. Most of the main code is his and naturally he gets pissed off.

So I learn how to push stuff back and at the same time ask users to help. EOSM gets ported back. After all, neither of us here can do all of it and still have any kind of life. The only thanks is really having happy users and maybe getting cool stuff happening in your own projects/uses. Yea, speaking of that, I have drama here. I pretty likely have to sell + move to another state or get involved in a legal battle where I win but really gain nothing besides more expenses and the same shitty life. I've been doing contract work for all the time I've been working on ML (see where all that free time came from?). But yes, all, this is not your problem. you just want camera software. On top of that the implication FEELS like throw out your work and cease to exist. I'm probably going to be late because I sat and typed this out and maybe it got a little shitily written towards the end.

Anyways, these are/were my motivations. I just don't feel good about any of the hostility or schism from what essentially is my first real coding project and mostly a thankless labor of love. At the same time I don't like letting ML down and pissing off A1ex to the point he wants to quit. So everything seems like its burning and I feel like shit and there you go.

I think it started actually staying on longer after the refactor. I just see the canon dialog for a second on the screen.

It might be worth testing the edmac flags that caused this resolution resolution restriction in general.

uint32_t dmaFlags = 0x40001000; // "enhanced"

vs
   
uint32_t dmaFlags = 0x20001000; //Original


I recorded some more on 7D/6D and not really sure about the improvement... On 6D ended up struggling with 720P and indicators took a long time to say continuous. Interestingly though at a higher res I got a few, maybe 20 more frames. 7D took longer to reach continuous too and write speed jumped all over the place. Slurp still seems like its set to the original flags and I think I may have changed them to the "enhanced" ones by mistake, leaving the originals for normal raw. Maybe the restriction + original flags are the best as it exposed some underlying problem and would explain why some resolutions performed "better".