Messages

[does not cover lost parcels]

For those unfamiliar with PayPal, they will refund you themselves if you dont receive your item, or if they consider it unlikely that your product return will ever reach the seller, ala returning things to China, or if the cost of the item new is similar cost of return postage. IMHO PayPal is worth it. So far they have been excellent for me in cases like this.

I think you're mistaken: the paypal buyers' protection does not cover lost parcels (read the fine print)... or did you ever get your money back even for lost parcels when the sender could prove they've sent the item on its way but for matters unknown it didn't arrive?

I'm aware of how to dispute PayPal transaction. But I was pretty sure they will solve the problem themselves. They asked me to wait for 3 months and there is just 45 days to dispute the transaction on PayPal.

The smart idea is always to dispute after 45days if the delivery hasn't arrived no matter what or you're at the mercy of the seller. Signaling a bad ebay rating is also a good idea, or in costly cases forum posts which are sure to be picked up by google.

Now they send me email with offer " issue you a full refund if you remove your post from the forums.". No guys, you don't shut me up this way. Let it cost me 150 USD, but I want others to be warned.

Thanks, though I fear it won't be any good in general - there are too many china sellers so the other fishy ones will just continue with their business practice, they're so cheap for a reason. Still, I keep buying from china because domestic sellers have ridiculous premiums for small camera items that cost cents from china but tenth of € from europe.

One question: After 1% seems to have left and the fork whose name shall never be uttered again doesn't receive any new commits, what's the current perspective of ML on 6d?

I'm not arguing to stop building 6d nightlies, on the contrary, but are there any new upcoming features like the patch manager for mini_iso and dual_iso which cannot be ported to the 6d unless a 1%-quality dev appears out of nowhere? Or is the new code expected to be so high level that even mere users can port it to the 6d with some trial and error procedure?

In any case, imho it should be mentioned here again that currently the advice concerning 6d is "don't get this camera if you want a trouble-free ML experience".

The problem is my 500D is not entirely mine, it's my father's so I am really really scared to install a nightly. Are they safe now ?

Even the current "stable" ML on your 550d is not "safe", and a satellite might come crashing down right now and kill you where you sit. But concerning "nightly": It's the "new stable" and is probably better bugfixed than the old "stable" version" because all development nowadays happens in branches, new code is only merged after testing.

If not, or if additional firmware images are wanted, I can (try to) provide dumps for my (german) 100D.

I don't think this is the bottleneck, any 100d maintainer would need a camera in his/her hands anyway and if he/she is up to the task then dumping the rom is the least of concerns. If it isn't done already anyway as there seemed to be some initial progress, and afaik there are only international roms so adding a supposedly "german" variant wouldn't help.

In the cameras' ROM there is a table with all the available menu items code.

Intersting to know and it's bound to be in the Canon code somewhere :-> but it could be useful for getting the stings of a certain cfn for the ml gui help line. But of course unless someone manages to extract the valid settings from the Canon rom, we'd still need a ml-filled static lookup table for each model.

Did you need something specific, or just what each function does on each body, so you can spot the odd ball cases?

What would be useful is a cfn_check(int cfn_group, int cfn_number, int cfn_value) core function that checks via a lookup table if some cfn value is valid. The function would return 0 if everything's peachy, or 1 if the cfn doesn't exist on that camera or the value is out of bounds so a warning can be issued in the help line.

There are lots of potential cfn functions that users might want to toggle with a hotkey, and I'd let them figure out for themselves what cfn does what so the gui menu would only allow them to choose cfn x.y=z with numbers ... but ML shouldn't give users to brick a camera with wrong gui settings.

There is prop_request_change_wait; if I understand it well, it's exactly for this use case

Great, that's exactly what I'm looking for - thanks!

EDIT: Um, in the core code there are various values for timeout - from 100 to 1000: What would you say is a reasonable timeout setting for an iso change? If the timeout is too long and prop_request_change_wait is called in the (module) shoot task, will that drag down the system?

funny man.

I try to :-) ... it's just that if you read the thread you should have a clear understanding what is required to get a port working, if still in doubt look at the neighboring 70d thread that recently has found a maintainer.

I guess you know the issue as it affects various modules: How do you detect if a user changed a property when the ML code also changes it?

Example: In auto_iso, I want to disable the module when the user changes/overrides the iso value. But since there is a lag between setting a prop and it being actually changed I cannot really tell if it was the code or the user that changed it:
1. current iso: 400 -> code sets it to 200
2. next shoot_task cycle: code detects "still 400" -> is it not yet changed to 200 or has the user set it back to 400?

Question: I recently saw some time detection (I guess it was alex' code?), but I don't quite remember where. Is there some rtos-like max. delay when I can say that the prop should have been changed by then?

I'd like to add some c.fn toggling to my hotkey module (esp. switch to different af tracking "scenarios" on 6d by modifying the 3 relevant c.fn settings).

I'd currently hardcode this for my 6d, but I could also add a gui for "set c.fn (enter value).(enter value) to (enter value)." Alas, I certainly won't read all Canon manuals what c.fn settings are valid on what model, thus the question: Can users brick cameras by setting c.fn to out of bounds values - or does Canon code simply ignore wrong settings?

Is there anything in the works concerning an abstraction layer to tie specific settings to the lens that is on the camera?

Currently, I'm (nearly :-)) about to hardcode my 3 lenses into my auto_iso module so I get lens-specific min. shutter settings in av mode - but I can imagine lots of other options (Canon and ML) that I always switch based on the lens I'm using as they indicate different "shooting scenarios".

If the core would provide some framework for this, other modules might also profit from this ... but alas, as always it probably needs some time-consuming gui work next to the backend.

Especially for Prime Noise Reduction

+1, I'd really like to process some of my old 60d dng-converted raw files with "prime". Alas, dxo specifically blocks reading canon dng for corp policy reasons (i.e. they always find different answers why it cannot be done, see their forum) ... so it might not be as easy as changing some exif tags to make their software read canon dng

Your best bet probably is to write a raw dng->cr2 (re)conversion tool, the adobe guys say there's no problem there but they aren't interested in doing it atm.

Thank you a lot Marsu42, I can't wait to try it

Let me know if it works as a drop-in mo without any other core dependencies (I expect it to, but didn't test it) and if you have any other feature suggestions. Right now, it just copies av/tv/iso from the chosen p/av/tv mode to m.

praying they did

Don't pray, code!

Religion is the sigh of the oppressed creature, the heart of a heartless world, and the soul of soulless conditions. It is the opium of the people. (Karl Marx) :->

Very interested to try it on the 60D

Here you go, single-feature only, I just saw everything else requries core patches and wouldn't work with just putting the .mo into the camera:

https://bitbucket.org/Marsu42/ml-pull/downloads/lazyhelp.mo

I am glad to help; I can shoot video clips and try some things, if that would be helpful.

Nice you're participating, but the current problem is not to find people who can try some things, but for devs who can code some things that cannot be copy/pasted from other cameras :-o

Chmee brought up the point that Adobe aren't interested in supporting ML. Well gee-whiz, I wonder why?!?!?!

Because the near-monopoly market leader won't adopt software they don't control into their core workflow.

[Raw error]

Hey guys! I just tested the ETTR feature on my 5d mark iii and i get a "Raw error" message.

Do you also have jpeg enabled next to raw? That's the culprit on 6d.

[Already Done] Instant image sync to the government (NSA)

Those who have nothing to hide have nothing to fear! If all images would be synced to the NSA or - even better - you would have a 24/7 built-in camera attached to your head, you could even prove you're innocent and would be safe from being hauled of to a little place near Cuba or some charming east European CIA facility where nice people ask you some innocent questions

I'm wondering if there's any speed vs. iq tradeoff in current cr2hdr? That's because at least on my laptop it's so slow anyway I'll let it process the files when I'm not around ... so if a "--ultra-slow-highest-quality" setting would be there I'd certainly use it :-)

Unfortunately for some of you, this is not exactly my intention, and GPL is just a tool to prevent such situations from happening. I could have given this code away as public domain, but I chose to protect my work from being used without giving back.

Next to thanking alex, g3gg0 and the rest of the devb team again I'd like to comment that building a community seems to work (even though I'm lagging behind what I'd like to share back. The reason I sit down at all and polish up code for merging is that I feel obliged to the project and it's essentially non-commercial.

Imho the current community building is only possibly because of the gpl system, my understanding of lgpl is that this is created for cases when the oss software wouldn't be adopted at all because vendors cannot or don't want to share their source and would use (probably inferior) commercial libs instead... so lgpl is a "2nd best" option to inject oss software into the closed software industry and to creat alternatives to existing commercial software, not to enable making money from integrating other people's work into source code.

My observation: the current gpl seems to work with the exception of the "usual suspect" big lgpl projects - there are lots of companies out there successfully packaging gpl software and providing support for it. With the lacking ML docs, this is surely a field that could generate money w/o undermining the "share code back" idea.

It would be great to press one button to copy the three settings to the Manual mode

I integrated this in one of my (currently personal and part of my infamous "to be released" queue) modules, it's called "copy to m": Select a mode (p/tv/av) in the menu and then the setting from this is copied to m mode once you turn the dial to it.

I use this all the time for focus stacking, figure out the exposure in semi-auto and then do stacking/bracketing in m ... if you really want it I can upload it as a single-feature module and cut out all the other wip stuff.

Therefore no messing around with focus motors.

Right, thanks for explaining, would have been to good to believe if they managed to speed up stacking with lens af :-p

... so the capable people around here can concentrate on the "very slow" side again, full res silent pix pretty please with flowers :-> ... my 100k 6d already is at 40k, no way I'll do 40frames+ focus stacking with this piece of equipment.

The latest versions of Helicon remote have a feature called "Burst Bracketing" - after pre-setting the max. fps of the attached camera it does this: http://www.heliconsoft.com/helicon-remote-history/

New feature - burst bracketing (combining continuous Stackshot movement with burst shooting to shoot focus stacks rapidly - in a matter of seconds)

Obviously, if this is possible this should go into ML asap :-) as it fixes the main shortcoming of focus stacking - the crawling speed which leaves you with broken stacks when the (natural) light changes.

nanomad... I saw you mentioned you were interested in the possibilities with WiFi on 70D.. I would be interested to see what evolves from that also..

+1, this would also cover 6d and most likely a lot of other future canon eos models.