Messages

What about --embed-original-move and --embed-original-copy?

Yup, sounds very reasonable.

Another thing I didn't think about: if you keep the CR2, and you also embed it in the DNG, you won't be able to reprocess the DNG (since it will try to extract the CR2 and it will fail, because the file is already there).

Well, then check if the cr2 is already there and then don't extract it from the dng :-p as it is bound to be the same as the embedded one? Or extract the cr2 to a temp directory and then process it from there, I already mentioned a temp working directory for all the exiftool stuff would be nice and not to dump the temp files wherever the original is (network drive, cf/sd card, external hd...).

so, for me, the expected behavior is to move the original and embed it into the DNG.

Yes, you're correct, but I couldn't help but comment that from my programing and IT experience extra-super-high care and explicitness for "deleting" files from apps is advisable.

so, for me, the With this option (CR2 moved into DNG), you have 3 choices: - make a few copies of the CR2, and process the copies (easiest IMO)

Sure, creates some overhead because I copy a file and then delete it, but of course no problem there, fortunately I don't need a gui for cr2hdr :-p

I can add an option to --keep-original, but in my opinion, the default behavior should be to delete the original.

+1 from me

there are no API in LR to delete an image from the catalog, but you can delete the file... but it remain into the catalog without orignal file

Well, you can always do a "find missing" and then manually remove it, if you didn't know this option.

Just found the exiftool command that does this.

Terrific, thanks, I never managed to read through the exiftool doc page :_p ...

1. There is a warning after I try to re-process some random dual_iso file - link to sample: https://bitbucket.org/Marsu42/ml-pull/downloads/DUAL2668.CR2

Code Select Expand


Input file      : DUAL2668.DNG
DUAL2668.CR2    : extracting from DUAL2668.DNG
Warning: Bad compressed RAW image - DUAL2668.DNG


2. Deleting files w/o explicit user request seems like a bad idea, imho it would be advisable to add an option for this like --move-original or an additional --delete-original, whatever you like. Reason: Sometimes I process dual_iso images with different options (soft film curves) right away and then delete the ones I don't like in Lightroom.

but i guess its not popular enough for dedicated dev?

Well, the devs seem to be able to afford a 5d3, I would if I could :-p

any ideas?

Learn to code and become a dev yourself? Or be happy ML works at all on the 6d as it's basically unmaintained.

I'm trying to build ML using Fedora 20 using the 'summons-arm' script and have stumbled across a problem.

Just don't, use the arm toolchain from launchpad or you'll run into no ends of tiny problems and always wonder when some problem occurs if ML or your custom compiler is the cause.

https://launchpad.net/gcc-arm-embedded/+download

cr2hdr is processor bound.

Not if you're processing the files directly from the cf/sd card as the temp files also end up there, you have to copy the files first off the card or you're killing the card with additional r/w cycles and the speed is crawling. This and the unc path problem imho are enough to warrant a "temp file path" option.

There seem to be a few reports of the same problem.

The 6d is basically unmaintained, though fortunately remains in the "nightly compilation" group atm. Afaik since 1% stopped committing and in his repo only works on eosm and 7d, there is no dev left with access to the camera

Looks like the CR2 files are on a network path; try copying them to a local directory.

... or assign a drive letter to the unc path, many windows programs still cannot handle them. You'll still copy the temporary files over the network two times, if that's a problem.

Speaking of which: Probably cr2hdr deserves an option to assign a temp working directory where to copy/process the intermediary files, people could also use a ram disk or their fastest drive where the temp dir should be. This would also be handy if processing dual_iso files directly from the sf/cf card.

Offtopic:

This.

Done. It took a little more than 10 seconds, and it's not yet fully idiot-proof.

Yeah, that's why I like delegating tasks :-p because in my ML experience things are seldom as easy as they appear: multitudes of different situations pop up out of nowhere, not to mention the support for all eos models which you'll never see or own. Still, you're the most qualified person for dealing with the unexpected, thanks :-) !

Good point. [...] Meanwhile, preview correction working fairly well [...] but keeps the weird cast

I cannot test it atm since my laptop's sd card reader is going crazy, but sounds like a reasonable approach. Still, I'd +1 for the monochrome option since (next to the ! sign) the color cast is really distracting and doesn't help much to predict the final look, even with some dual_iso experience - ymmv.

if you are bored

In that case, I'd work on my modules :-p ... though I could probably manage a pull request for monochrome picstyle on dual_iso_is_active(), but I'd really really rather have you do it in 10 seconds.

The added goodie of this solution is that (at least on 6d) you can make the camera display a ! in the *viewfinder* that is otherwise inaccessible to ML so you could immediately see if dual_iso is enabled or not!

We could start with a generic metadata library

One step further towards some keyword tags in the sidecar file :-)

and monochrome picture style.

Good thinking there, I think this deserves a "set picstyle to monochrome" setting in dual_iso to eliminate the magenta/cyan distraction!

i would then add it to the new sound system.

Great, thanks, I'll mark it as [DELEGATED] :->

module init only runs once, or you could make a task that doesn't loop and just exits, or put it in shoot task before the loop starts

Oh my, good point, I completely forgot I can put custom code there. Thanks!

Could beep_custom() please be amended with an option to set the volume of the beep sound? Currently it's only global, but an added volume setting relative to that, i.e. producing quieter sounds (maybe in steps 1-10 or whatever) would be very welcome. Reason: I want to have quieter "notification" sounds and louder warnings.

for example I can't undestand how many pictures to take. Who decides and how ?

It's calculated by the distance between start and end with your selected step size - but it says how many pictures it will be next to "Run focus stack".

PS : If I was a progammer or if I had the capabilities, be sure I would propose my help and skill.

Um, don't make it *that* complicated, when in doubt just use "dumb" focus bracketing: Simply select a your step size, then a large number of pictures behind, manual focus the lens to the front and run the stack. When the stack has covered what you want to shoot, stop it manually (press SET).

+1! I really need this feature. Is there any news on the matrix being ported? Is there anyone who knows how to do it willing to do it? I can try and do it myself. If I were to try how is is the code modified to port it.

The old matrix code is in the old Magic Lantern v2.3, get the old source from bitbucket via hg update to an old revision. Not that this code never got "full res" as the zoom box couldn't be positioned to the very sides of the frame. If you have that, I imagine you could just attach the new dng code to it instead of just saving the 422 buffer (but I didn't look at it at all).

Alex had some suggestions on how to improve speed a lot, search the forum or if you're not successful and want to work on it pm if he doesn't read this anyway.

Edit: Or *cough* $100 if someone can do it

Hope it helps, I also want the feature though I'm not a big fan of features for money - but the people who come to my mind and are able to do it don't do it for money and are busy on other features.

I'd like to add a small function that resets the af point to center if I turn on the camera. Where do I hook this function w/o executing it all the time in shoot task as I usually do? Thanks!

Is there anywhere I can see the source for that code? Was it a module or can I just look at an old version of silent pic?

It's in the old "stable" v2.3 code before the modules were introduced, but it only worked for directly grabbing 422 and not raw data. You then had to run a python script to assemble the pieces to a frame, and it wasn't full res since the zoom box could not be set to the very edges of the frame or Canon kept resetting it.

Alex had some thoughts on how to solve these problems and speed up the process, but he never came around to implement it - pm him if you want to work on improving the silent module and don't find his ideas.

Instead I meant variance between exposures as the amount of cloud cover subtly shifts.

Unfortunately, moving clouds don't just change the global exposure level but always change lighting direction and characteristic a bit (or I wouldn't have had so many broken outdoor focus stacks :-p).

Is this implemented anywhere or has anyone experimented with this yet? (bump)

Just bumping this won't help, the people who are up to implement full res silent pix are the main devs and those are a) not interested in it too much and/or b) busy doing other coding parts. Alas, I personally really miss the matrix code from the old implementation, just resurrecting this with raw dng would be at least an improvement even if it took a while to take a pic.

This will not work out for everyone. Marsu42, I'm not a programmer (I really suck at it) and have to rely on other persons to pick up my ideas and make them work (or decline them). And when it comes to focus stacking this person is you, I suppose.

I also wasn't born a programer, you know :-p ... small fixes are really not that hard. But of course I know that most people cannot do it, I just want to note the character of the ML project again to people drive-by requesting improvements.

But if you have any non-meta-discussion suggestions feel free to request some specific (new) improvements in the feature requests section. Actually the whole focus stacking and rack focus code could use some refactoring as a module, but alas, I'm too busy to do it atm esp. as the current solution is working fine for me.

I will engrave on my LCD screen "here" = "start point" 

... or just sit down, change the source code and upload a pull request as everybody else with some coding skills does when he doesn't like something about ML or wants to add a feature.