Messages

Probably a long shot; but I've had issues with graphics intensive programs on a MacBook Pro in 10.10.2.

Turning off transparency helped quite a lot for me (System Preferences --> Accessibility --> Display --> Reduce Transparency).

Phil.

Changing the card name makes no difference on mine - at the moment mine works correctly with all lenses.
I'm trying to make the problem happen rather than fix it, so I can try and diagnose the cause.

The problem stopped on my camera after a low level format of the SD card in the camera, and has not returned since.

Phil.

The 2011 MacBook models did not have USB 3.0 ports as far as I know - a USB 3.0 reader should still work; but you will not get the full speed.

I have used this one for a number of years on both a 2012 MacBook Air and a 2013 MacBook Pro. It works fine in Mavericks and Yosemite.
http://www.amazon.com/Lexar-Dual-Reader-Professional-LRW307URBNA/dp/B007FEFQDA/

Phil.

@Walter - I have both OS X and (shudder) Windows 8.1; but can't reproduce the problem.

Tried renaming the plugin folder in windows explorer; which removed the plugin from LR - when I re-added the plugin to LR it continued to work correctly in the new directory.

Did you do something different?

Phil.

Just installed "Windows 7 Enterprise 32-bit, german" on a virtual machine (VMware Player). Added all essential MS patches. Downloaded LR 5.6 installation file from Adobe's site and installed it (german again).
*No* settings changed. Run import to copy my test file to C:\Bilder. Added a keyword, opened context menu and selected "Metadaten" (= Metadata in en) and "DNG-Vorschau und Metadaten aktualisieren" (= "Update DNG preview and metadata" in en).
Filesize after that: 21,736,646 Bytes. Shrunk again.
I can upload the VM if needed.

Ciao
Walter

That's what I see on OS/X - and I would expect it to be the same on all platforms.

LR saves DNG files with lossless compression, unless you enabled the lossy compression setting (Preferences --> File Handling).

Your original DNG file is not compressed, so when LR updates the preview and re-saves the DNG file it compresses the main image data.

Phil.

I have the toolchain setup on my windows machine now, using gcc 4.8.3, and Cygwin.
When I make 7D.203 it compiles, and ML boots on the camera, but as soon as I try to use the raw module, the camera freezes and I have to pull the battery. Has anyone else experienced this? What was the solution?

I am a little unclear about which files I need to copy to my card, I don't see all the same stuff that comes packed in the nightly builds.... I have tried just keeping the files from nightlies on my card and just replacing the autoexec and .fir, but this results in freezing when a module is activated.

I had this at first on my 5DIII - until I updated the .sym file in the modules directory.

When you rebuild, it should create a 7D_203.sym file in the platform directory, copy this to the modules directory on the card and see if it helps.

Phil.

yes phil, I right click on virtual box and select "run as administrator" any other hints?

Could be anti-virus conflict - see https://forums.virtualbox.org/viewtopic.php?f=6&t=62615

Phil.

I'm trying to use the prebuilt at work and when I try to launch the Magic Lantern machine,  I keep getting this:

Failed to open a session for the virtual machine MagicLantern.

The virtual machine 'MagicLantern' has terminated unexpectedly during startup with exit code 1.

Result Code: E_FAIL (0x80004005)
Component: Machine
Interface: IMachine {480cf695-2d8d-4256-9c7c-cce4184fa048}

On Windows, any error code ending in 005, is usually a permission problem (access denied).

The machine may be locked down preventing VirtualBox (or whatever hypervisor you are using) from gaining enough access to the hardware.

Have you tried running it as administrator?

Phil.

I'm not really able to debug issues with mlv_dump because I can't compile it due to GCC issues with '-mno-ms-bitfields' (I'm on a Mac and Apple's flavor of GCC has dropped support for '-mno-ms-bitfields').

Install GCC 4.8.2 using macports (http://www.ficksworkshop.com/blog/14-coding/65-installing-gcc-on-mac).
This will also give you nested functions so you can compile cr2hdr if needed.

Phil.

[Edit:]

@philmoz: what exposure settings did you use? If one of them was auto, that would be interpreted as 0 (which is not valid). These routines were meant for factory testing, and they do behave a little different than regular pictures (they use a separate code path in scsReleaseData, codenamed FA DARK_MEM1)

Thanks, was using Auto ISO - setting manual ISO fixed that problem.

Also got this crash a few times - not sure how to reproduce it; but may be from switching to full-res after taking a few silent pics in simple mode. Last time this happened the camera locked up when turning off (had to pull the battery).

Edit: reproducible on my 5D3. Take a Simple mode silent pic. Switch to Full-Res mode, get 'Raw Error' when half press shutter and Err 70 when full press shutter.

Code Select Expand


ASSERT: GetMemoryAddressOfMemoryChunk( GetFirstMemChunk( pMem1AllocateListItem->hMemSuite ) ) == pMessage->pAddress
at SrmActionMemory.c:1619, task RscMgr
lv:0 mode:3


Magic Lantern version : Nightly.2014Jul18.5D3123
Mercurial changeset   : b1838cf8d136+e0a1e77aeb30+ (fullres-silent-pics)
Built on 2014-07-18 09:30:21 UTC by xxx
Free Memory  : 167K + 3893K


Phil.

Tried this on my 5D3 (fw 1.2.3).

Grabbed the fullres-silent-pics branch and merged the 5D3-123 branch into it.

'Simple' mode silent pics works ok; but full res crashes with Err 70.

Crash log:

Code Select Expand


ASSERT: 0
at ./Param/HivshdParam.c:64, task ShootCapture
lv:0 mode:3


Magic Lantern version : Nightly.2014Jul18.5D3123
Mercurial changeset   : b1838cf8d136+e0a1e77aeb30+ (fullres-silent-pics)
Built on 2014-07-18 09:30:21 UTC by xxx.
Free Memory  : 167K + 3895K


Phil.

[Edit:]

I did a quick test on OS/X and the compressed DNG does get created; but with the wrong output filename.

For example if I issue a command like:
  "Adobe DNG Converter" -dng1.4 -o "/somepath/fileneme.DNG" "/somepath/filename.DNG.DNG"

I end up with an output file called:
  /somepath/"/somepath/filename.DNG"

In other words the file is in the correct directory; but the filename includes the directory path in the name (OS X allows forward slash characters in filenames).

Perhaps the Adobe DNG Converter is expecting only a filename for the -o parameter; not a full path.

Will test on Windows when I get a chance.

Phil.

Edit:
Checked the Adobe documentation for the converter - the '-o' parameter only accepts a filename, not a full path. It defaults to saving the output into the same directory as the input file. The '-d' parameter can override the output directory.

On OS/X it creates a badly named file as I outlined above, on Windows the converter silently fails and produces no output.

Still figuring out the whole mercurial pull/branch mechanism so in the meantime here's a diff patch that fixes the problem for me (only tested on OS/X so far).

Code Select Expand


diff -r 30a513223c01 modules/dual_iso/adobedng-bridge.c
--- a/modules/dual_iso/adobedng-bridge.c        Wed May 07 13:34:25 2014 +0300
+++ b/modules/dual_iso/adobedng-bridge.c        Wed Jun 25 18:46:37 2014 +1000
@@ -92,6 +92,15 @@
     snprintf(tmp, sizeof(tmp), "%s.DNG", source);
     rename(source, tmp);
     
+    // Find filename part only, '-o' parameter to DNG converter does not accept path
+    const char *src_filename = strrchr(source, '/');
+    if (!src_filename)
+        src_filename =  strrchr(source, '\\');
+    if (!src_filename)
+        src_filename = source;
+    else
+        src_filename++;
+
     char compress_cmd[1000];
     char* start =
#if defined(WIN32) || defined(_WIN32)
@@ -99,7 +108,7 @@
#else
     "";
#endif
-    snprintf(compress_cmd, sizeof(compress_cmd), "%s\"%s\" -dng1.4 %s -o \"%s\" \"%s\"", start, adobe_dng, lossy ? "-lossy" : "", source, tmp);
+    snprintf(compress_cmd, sizeof(compress_cmd), "%s\"%s\" -dng1.4 %s -o \"%s\" \"%s\"", start, adobe_dng, lossy ? "-lossy" : "", src_filename, tmp);
     printf("%s\n", compress_cmd);
     int r = system(compress_cmd);
     if(r!=0)


These matrices are not in the original CR2 - they are created by Adobe DNG converter.

So is this hard wired into the DNG converter program or is there some other data in the CR2 file that it uses?

If the CameraCalibration matrices are specific to a particular camera (not model), then there should be some data in the CR2 file that Adobe is using.

Unless the different values I'm seeing are because it's a new version of the DNG converter.

Phil.

I thought I'd point out a relevant thread regarding the calibration matrices and illuminants: http://www.magiclantern.fm/forum/index.php?topic=10119.0

Thanks for that.

Didn't realise that the CameraCalibration matrices were actually camera specific (my 5D3 is very different to the values in that thread).
Removing these two matrices makes the problem worse than the current single matrix and illuminant - back to the drawing board.

Phil.

When the 20-bit branch will be merged back, the modified raw_info structure will not be funny.

What about updating the matrices via exiftool, at the end? May be a little slower, but we already call exiftool to copy the tags from CR2.

The version of exiftool I'm using (OS/X 9.63) doesn't understand the color calibration data from CR2 files - if it did then these tags would already be getting copied.

Maybe it's an exiftool problem on my system? Do you see the additional tags in your converted DNG files?

The idea I had for the raw_info struct would be to use a custom #define to allow cr2hdr to include the additional data:

Code Select Expand


    int32_t calibration_illuminant1;
    int32_t color_matrix1[18];      // DNG Color Matrix
#if defined(RAW_INFO_EXTRA_CALIBRATION)
    // Include additional color calibration details in DNG file for cr2hdr
    int32_t calibration_illuminant2;
    int32_t color_matrix2[18];
    int32_t camera_calibration1[18];
    int32_t camera_calibration2[18];
    int32_t forward_matrix1[18];
    int32_t forward_matrix2[18];
#endif


Phil.

[Type]

There is a small discrepancy in the white balance Temp & Tint values shown in Lightroom for a dual-iso converted DNG, compared to the equivalent normal CR2 image.

Example:

Type	Temp	Tint
Normal CR2	6000	+6
Dual-ISO DNG	5900	-3

The AsShotNeutral values are the same, so the white balance calculation in cr2hdr is working - at least for this image.

The difference is not very large, so it might not be worth the effort to fix; but I have found a way to make Lightroom calculate identical Temp and Tint values.

The solution is to include the ColorMatrix2, CameraCalibration1, CameraCalibration2, CalibrationIlluminant2, ForwardMatrix1 and ForwardMatrix2 values for the camera in the DNG file. It also requires setting CalibrationIlluminant1 to 'Standard Light A' and CalibrationIlluminant2 to D65.

I've tested this with cr2hdr 'classic' (5D3-123 branch), and with cr2hdr-20bit.

At the moment my fix changes the raw_info structure, which a1ex tells me will break compatibility with other things.

I can probably develop a fix without modifying raw_info; but I'm not sure it's worth the effort - is anyone interested in having the additional color calibration data in the DNG files?

Phil.

On my side I have this problem since Xcode update to compile cr2hdr.

I need to remove -mno-ms-bitfields to be able to compile

Or you can install GCC 4.8 or 4.9 (using homebrew or macports).
http://www.ficksworkshop.com/blog/14-coding/65-installing-gcc-on-mac

This will also allow you to build the new cr2hdr-20bit version of cr2hdr - XCode does not support nested functions.

Phil.

For relevant discussion and testing, go to http://www.magiclantern.fm/forum/index.php?topic=10265.0.

Many thanks, will continue the discussion there.
Ignore most of what I posted previously - seems I was chasing the wrong problem

Phil.

Hope this is the right place to post this

I've been playing with dual-iso (5D3-123 branch) and noticed that the white balance Temp & Tint values in Lightroom (5.3) on the converted DNG file from cr2hdr did not match the original CR2 values.

After a bit of digging through the code, and playing with values I've found the following:
- the AsShotNeutral calculated using the RawMeasuredRGGB tag appears wrong, this tag gets used if the camera is set to Auto WB
- using the RedBalance & BlueBalance tags from the CR2 give the correct AsShotNeutral (as compared to a DNG converted using the Adobe DNG Convertor)
- using the WB_RGGBLevelsMeasured tag also gives the correct AsShotNeutral

The comments in exiftool-bridge.c state the RedBalance and BlueBalance values are not trustworthy - does anyone know why? They seem to work ok on my 5D3.

After fixing the AsShotNeutral value, the Temp and Tint were now closer to the original CR2 values in Lightroom; but still not exactly the same.

Looking more closely at the cr2hdr generated DNG file I noticed that only one color matrix is being saved - time to get the latest DNG code from CHDK

After adding the second color matrix array, both calibration arrays, both forward matrix arrays and setting the correct value for illuminant1, I'm now getting consistent WB Temp and Tint values in Lightroom.

So far, the code changes to do this are in:
- src/raw.h (updated raw_info struct)
- src/chdk-dng.c (additional DNG tags)
- modules/dual-iso/cr2hdr.c (init raw_info)
- modules/dual-iso/dcraw-bridge.c (populate raw_info)
- modules/dual-iso/exiftool-bridge.c (get white balance)

Since there are changes to the core files I'm not sure what other impacts this may have - need to do some more testing.

Lastly, what's the preferred place to post patches for ML?

Phil.

Hey, CHDK guys are always welcome

g3gg0 explains it here: http://www.magiclantern.fm/forum/index.php?topic=6785.msg58899#msg58899

It may be helpful to load these dumps in QEMU: http://www.magiclantern.fm/forum/index.php?topic=2864
(basically you need to get the "gaonisoy" part at 0xFF0C0000; the QEMU log will tell you a bit more about where each ROM is mirrored)

Thanks, seems to be working now. Must not have looked closely enough at the original dumps - they're a bit different to the P&S versions

Phil.

Apologies if this has been answered previously.

In the current 5D3-123 source the backup_task (boot_hack.c) and dump_rom_task (debug.c) code both dump two 16MB regions from 0xF0000000 (ROM0.BIN) and 0xF8000000 (ROM1.BIN).

When I look at these they are both empty (filled with 0xFF).
When I checked the ROMBASEADDR for the camera is shows as 0xFF0C0000.

Shouldn't one of the dumps be starting at 0xFF000000?

I finally managed to compile from the source and when I changed ROM0.BIN to dump from 0xFF000000 I get something that looks more like a Canom firmware dump.

Thanks,
Phil.

Thanks for the great work, with the Magic Lantern, it makes Astrophotography on EOS M become very easy.
I have done a few test shots using intervalometer.
Here is the photo : http://www.flickr.com/photos/91111311@N04/8274354228/
But I found that after installing ML on EOS M the 18-55mm couldn't release the shutter, I have to dismount and put it back in order to shoot.
I have uninstall ML and everything back to normal.
Any thoughts?

Works fine on my camera.
Tested with 22MM EF-M, 18-55 EF-M and 40MM EF (with adaptor).

Phil.