50D: bugs and some missing features

[50mm1200s]

I'm using 50D professionaly for MLV video. So far it's working very well, thanks to all the hard work of you developers. I've noticed some bugs and missing features, maybe someone could answer me if these are really bugs or not:

1 - Sometimes while recording with MLV the camera gives an error. The message is something like "card/filesystem error". The card is formatted inside camera (exFAT, from what I remember). Everytime it happens I have to restart the camera (most of the time removing batteries).

2 - The Auto-ETTR module uses the "SET" button, the same as the MLV module, so there's incompatibility between the two.

3 - Dual ISO doesn't seem to work in movie mode, even though the MLV module is loaded. The message (in orange) says: "Dual ISO does not work in movie mode on your camera".

4 - No shutter fine-tunning. If find it useful to get exact 180 degree shutter on 24fps...

5 - A slight magenta 'corruption' in the midtones. I'm sure it's not a WB issue or chromatic aberration. I'm processing with MLVProducer, so it could be a bug on post-processing, haven't tested on other software.

6 - The maximum resolution is 1568px? When I try to reach a higher resolution it gives me the message "[resolution] is not possible in current video mode (max 1568)", so when I return to a lower resolution it goes to 1536px, instead of the supposed maximum 1568px. It doesn affect the functionality, it's just a bug it seems.



I can send the log files and a MLV sample if needed, just ask here and I'll do the upload.
I have some dumb questions too:
- The 10bit doesn't seem to be supported on 50D, right?

- Is it possible to have the optimal ISO values on the "ADTG experiment" without compiling it from scratch? I've tried to run the ISO research modules, didn't work.

[Andy600]

My 50D is out on loan at the moment but I'll answer a couple of your questions.

1. I have not had this happen personally. Have you tried different cards? Carefully cleaning the contacts etc?

2. I think you can re-assign the record button!?

3. Dual ISO does not work for raw video in the 50D.

4. You can fine tune shutter settings but I don't get exactly 180 degrees either. It's either slightly more or slightly less (I choose slightly less). If very much doubt you can tell any real difference in cadence and motion blur against something shot with a shutter at exactly 180 degrees. And, in some 'pro' cinema cameras, although it may say 180 degrees on the settings screen they too can be one way or the other depending on the internal clock frequency.

5. It's likely not just in mid-tones but that's where you're most likely to see it. It could be CA or white balance. Try other apps for processing first. The white balancing algorithm in some apps can cause magenta contamination (I have seen it happen with raw footage in in Resolve) so that's where I would put my money. If its happening across multiple apps then try shooting a repeatable test without any tint offset being set in camera, try a different lens with a different focal length, try a UV filter, basically try everything you can think of in camera then try all the apps again.   

6. Sounds like a bug.

re: 10bit (and 12bit) it is not supported in the nightly builds (yet) but there are some working 10/12bit builds for the 50D. https://bitbucket.org/daniel_fort/magic-lantern/downloads/.

re: ISO values - no. For that you would need to find them using the ADTG build then edit and compile your own build. It may be possible with a script but I don't have a clue there.

[dfort]

- Is it possible to have the optimal ISO values on the "ADTG experiment" without compiling it from scratch? I've tried to run the ISO research modules, didn't work.

The module posted on the download page is suppose to run on the crop_rec_4k branch which the 50D can't do--yet. I compiled a build for you and put it on my downloads page. I'll keep it up for a few days or until you let me know that you've got it.

A few notes on those missing features that might make you feel a little better.

3. Raw video Dual ISO isn't working on several cameras. I think it might be a Digic 4 thing, IDK. However, if you could shoot video with Dual ISO you might not like it because it adds aliasing artifacts on top of the aliasing that is already inherent on these DSLR cameras. It is fine with still photography because you're using the full sensor resolution but at video resolution the Dual ISO artifacts are very noticeable.

4. Don't get too hung up on getting an exact 180 degree shutter angle. A few "professional" film cameras don't even have it. Ok, well maybe the better ones do for example the Arri 16s has 180° while the Canon Scoopic 16mm has a 170° and the Bolex H-16 has a 135° shutter. Some film cameras have variable angle shutters and the Panaflex Millennium can even vary the speed while adjusting the angle so the exposure remains the same. Though I doubt you're going to trade in your 50D for a Panavision to get that feature.

6. Yeah, that seems like a bug. Could you please write up exactly how to reproduce it and post it on the issue tracker?

Finally, the 50D users that have tried my 10/12bit experimental build have reported good results. It still needs more work but you are welcome to try it out. Please report your findings on the 12-bit (and 10-bit) RAW video development discussion.

[reddeercity]

3. Raw video Dual ISO isn't working on several cameras. I think it might be a Digic 4 thing

No they just need to find the cmos registers in ADTG_gui , just like the 5D2212_Video_dual_iso that @waza57 did  in Video - dual iso for 5D2
waza57 explains here how he found the registers , I would think the process should be repeatable with all digic iv cams specially 50D as it's the 5D2's little bro .

Code: [Select]

is_5d2 = 1;
        FRAME_CMOS_ISO_START = 0x404b4590; // CMOS register 0000 - for LiveView, ISO 100 (check in movie mode, not photo!)
        FRAME_CMOS_ISO_COUNT =          5; // from ISO 100 to 25600
        FRAME_CMOS_ISO_SIZE  =         30; // distance between ISO 100 and ISO 200 addresses, in bytes
       
        PHOTO_CMOS_ISO_START = 0x404b3b5c; // CMOS register 0000 - for photo mode, ISO 100
        PHOTO_CMOS_ISO_COUNT =          5; // from ISO 100 to 1600
        PHOTO_CMOS_ISO_SIZE  =         14; // distance between ISO 100 and ISO 200 addresses, in bytes

        CMOS_ISO_BITS = 3;
        CMOS_FLAG_BITS = 2;
        CMOS_EXPECTED_FLAG = 3;
https://bitbucket.org/waza57/magic-lantern/commits/7be4cd7f975ef25e98143d10da26712e5ec8ca77?at=dual_iso_video_5d2
dual_iso_video_5d2 source code for Video dual_iso.c works really well with 100 800 ISO only issue is super fast pans with freeze liveview , battery pull is needed then good to go

However, if you could shoot video with Dual ISO you might not like it because it adds aliasing artifacts on top of the aliasing that is already inherent on these DSLR cameras ........ but at video resolution the Dual ISO artifacts are very noticeable.

Never really notice anything different then usual in 1:1 FHD (it all depends on the content being recorded -- just don't film a brick wall unless your within 10 ft. of it   )
Where it shines the best is in 3xCrop mode with 10bit (old dec/'16 build)  but I really don't use it that much .

[aprofiti]

Regarding Dual Iso movie for 50D there is an old post of tecgen. This could be a starting point.

Another missing feature is flexinfo.
I made a pull request that enable it on 50D. Current issue is the flicker ofelements inside the center part of the screen. Also occurring with console screen (See below).
I was unable to test into unified due to compiling error I get with vanilla branch

Other bugs:
B1. Magic Zoom flicker a little bit. Maybe it is less evident In nighly than lua_fix derivatives. Need to retest a bit. See issue
2682

B2. Stopping h264 recording is done by pressing SET button instead of using half-shutter press. See issue #2332

B3. Console's windows is flickering in Photo display screen.
This should be a particularity of 50D. This was introduced (previously it wasn't evident because canon's display refresh was blocked) after refactoring console in lua_fix branch

[50mm1200s]

Thanks for all the replies.

1. I have not had this happen personally. Have you tried different cards? Carefully cleaning the contacts etc?

I haven't tried a different card, since I only have this one I'm using (Komputer Bay Pro 1000x)

2. I think you can re-assign the record button!?

Oh, that's right, thanks!

4. You can fine tune shutter settings but I don't get exactly 180 degrees either. It's either slightly more or slightly less (I choose slightly less). If very much doubt you can tell any real difference in cadence and motion blur against something shot with a shutter at exactly 180 degrees. And, in some 'pro' cinema cameras, although it may say 180 degrees on the settings screen they too can be one way or the other depending on the internal clock frequency.

Yes, you're right. I just find it annoying when I get ~178 degree instead of 180... maybe it's some psychological stuff.

5. It's likely not just in mid-tones but that's where you're most likely to see it. It could be CA or white balance.

It's not CA because it's happening not only on the edges and probably not WB too, because I've adjusted it many times. I checked the black point and sometimes it's off... maybe the software guesses the wrong BP?

Try other apps for processing first. The white balancing algorithm in some apps can cause magenta contamination (I have seen it happen with raw footage in in Resolve) so that's where I would put my money. If its happening across multiple apps then try shooting a repeatable test without any tint offset being set in camera, try a different lens with a different focal length, try a UV filter, basically try everything you can think of in camera then try all the apps again.   

I've tried on Rawtherapee (extracted from MLV with mlv_dump) and MLVApp.

Here's some examples below. Download a DNG here (1.83MB):
Link

Link

Link


The midtones have a cast of magenta, even though I've changed the ting levels to more green...

6. Sounds like a bug.

Yeah. Here:
Link

[50mm1200s]

I compiled a build for you and put it on my downloads page. I'll keep it up for a few days or until you let me know that you've got it.

Thanks @dford! You're awesome. Already running it :^)

3. Raw video Dual ISO isn't working on several cameras. I think it might be a Digic 4 thing, IDK. However, if you could shoot video with Dual ISO you might not like it because it adds aliasing artifacts on top of the aliasing that is already inherent on these DSLR cameras. It is fine with still photography because you're using the full sensor resolution but at video resolution the Dual ISO artifacts are very noticeable.

Too bad. I remember my 600D worked with Dual_ISO in raw video, I've found it to help sometimes when I needed more DR...

4. Don't get too hung up on getting an exact 180 degree shutter angle. A few "professional" film cameras don't even have it. Ok, well maybe the better ones do for example the Arri 16s has 180° while the Canon Scoopic 16mm has a 170° and the Bolex H-16 has a 135° shutter. Some film cameras have variable angle shutters and the Panaflex Millennium can even vary the speed while adjusting the angle so the exposure remains the same. Though I doubt you're going to trade in your 50D for a Panavision to get that feature.

haha!

6. Yeah, that seems like a bug. Could you please write up exactly how to reproduce it and post it on the issue tracker?

I'll see if I can post there. The reply above to @Andy600 has a link for a screenshot: basically when you reach above maximum resolution and then you go back not "<=" res. you don't get the maximum, but the value below maximum (1536px).

[50mm1200s]

Where it shines the best is in 3xCrop mode with 10bit (old dec/'16 build)  but I really don't use it that much .

@reddeercity can you explain what's de difference between 3xcrop and normal MLV recording? I've read @a1ex input on it and tested myself, but I can't see much difference between the two, except for the fact that 3xcrop has more noise and, well... it's cropped.

[reddeercity]

@reddeercity can you explain what's de difference between 3xcrop and normal MLV recording? I've read @a1ex input on it and tested myself, but I can't see much difference between the two, except for the fact that 3xcrop has more noise and, well... it's cropped.

One is pixel binding & line skipping , ever wonder why you only get 1536(Width) in Full Frame (4752/3=1584) needs to be a mod 8 number if I remember right so 1536
The other records every line and pixel no line skipping or binding plus you can have resolution greater then Full Frame Video -- e.g. 2000(w)x1080(h) @12bit=74.1MB/s (Max write speed)
http://rawcalculator.bitballoon.com/calculator_desktop
With Full Frame 1:1 you will or may experience aliasing and moiré pattern not so in 3x crop that the advantage .
you can record 1920x1038 23.976 14bit @79MB/s in 3xCrop , bit reduction just give you longer record times at higher rez.
If I had a 50D I would only record in 3xCrop (better to more resolution(1920) and little noise then less resolution(1536) ) you can always eliminate/fix noise with dark frame in post.

[50mm1200s]

One is pixel binding & line skipping , ever wonder why you only get 1536(Width) in Full Frame (4752/3=1584) needs to be a mod 8 number if I remember right so 1536
The other records every line and pixel no line skipping or binding plus you can have resolution greater then Full Frame Video -- e.g. 2000(w)x1080(h) @12bit=74.1MB/s (Max write speed)
http://rawcalculator.bitballoon.com/calculator_desktop
With Full Frame 1:1 you will or may experience aliasing and moiré pattern not so in 3x crop that the advantage .
you can record 1920x1038 23.976 14bit @79MB/s in 3xCrop , bit reduction just give you longer record times at higher rez.
If I had a 50D I would only record in 3xCrop (better to more resolution(1920) and little noise then less resolution(1536) ) you can always eliminate/fix noise with dark frame in post.

Wow, great. I didn't noticed that I could record 1920px in crop mode. Thanks for you reply.

[Andy600]

@50mm1200s

The problem is not the white balance unless you used As Shot or Auto.

I dialed in WB at 3850k (no tint) for a reasonably neutral balance but you won't get it precise without knowing the lighting or having a gray/white card target in the shot.




On the scopes it looks like you're also using a film lut or film look preset too? That is adding some heavy saturation to reds and magenta. The lut/look is also clipping highlights (quite badly) in the other shots and there's some unpleasant banding in the highlights. I would suggest trying to grade the look yourself or try a different lut/look but I see no significant problems with the DNG.

[50mm1200s]

@50mm1200s

The problem is not the white balance unless you used As Shot or Auto.

I dialed in WB at 3850k (no tint) for a reasonably neutral balance but you won't get it precise without knowing the lighting or having a gray/white card target in the shot.

On the scopes it looks like you're also using a film lut or film look preset too? That is adding some heavy saturation to reds and magenta. The lut/look is also clipping highlights (quite badly) in the other shots and there's some unpleasant banding in the highlights. I would suggest trying to grade the look yourself or try a different lut/look but I see no significant problems with the DNG.

Thanks Andy600. I'm using AlexaLog and then AlexaLog to Rec 709 LUT (from Arri website) on Lumetri. It still gives me pink midtones. Also, the highlight clipping happens all the time too, it is difficult to get a bright image just going +3 f-stops only on midtones, since it create a bad saparation between tones (maybe the banding comes from this)... well it's just my inability to grade properly.
The image you linked above seem to have wrong WB (too warm), maybe that's a point to consider too.

See the eye bags in this image, for example (edit: there's no makeup in the eyes):

[Andy600]

I suspect 'AlexaLog' is only the Log-C curve (1D) so if you're using an official Alexa 3D lut that transforms both the gamma and gamut from Log-C to Rec709 you will get these types of color problems.

You need to know the gamut that the image is in before applying a specific technical 3D lut or you are only compounding your problems. If you don't know the gamut it is safer to use only a 1D lut to get from Log-C to Rec709 and then add your own color correction (before the lut).

This also assumes also that 'AlexaLog' is actually using Log-C math and that there are no colorspace or levels issues in the app. Also, you really need to know which Log-C curve is being used because it changes relative to exposure. The default as used in most NLE's and color grading apps is EI800.

Where can I find AlexaLog? I'll check it when I have some time.

Re: WB. Maybe. I didn't do any grading, only set a WB. I'm going only by what I can see on a vector scope and there is no neutral target in the shot. The model has a pink complexion and the beautician/make-up artist is more of an olive color so cooling WB will tend to make the pink hues more blue and less life-like, especially under mixed lighting. If I were grading this I would certainly be using qualifiers to isolate and treat the different skin tones independently.

Try doing a basic grade without a lut and see if you still get clipping. +3 on mid-tones is quite extreme and yes, will likely cause some banding, especially if done after the lut. Why are you pushing mid-tones so much?

This is purely a subjective observation and you may actually be going for that look but I find the skin smoothing (possibly extreme noise reduction?) in 01.png to be way too much. It completely loses any texture in the skin and looks very unnatural. Try dialing back on the effects and you'll get a much better look

Are you using Lumetri in Premier or After Effects?

[50mm1200s]

I suspect 'AlexaLog' is only the Log-C curve (1D) so if you're using an official Alexa 3D lut that transforms both the gamma and gamut from Log-C to Rec709 you will get these types of color problems.

Yes, I suspected it was more complex than I thought.
MLVApp uses AlexaLog from this paper, it is indeed EI800. The ProRes color output is bt609 from ffmpeg. I think Premiere Pro reads it normally by default. The color matrix MLVApp is using came from ACR (actually you're credited in the source code for helping), so it's probably "precise" enough...

Re: WB. Maybe. I didn't do any grading, only set a WB. I'm going only by what I can see on a vector scope and there is no neutral target in the shot. The model has a pink complexion and the beautician/make-up artist is more of an olive color so cooling WB will tend to make the pink hues more blue and less life-like, especially under mixed lighting. If I were grading this I would certainly be using qualifiers to isolate and treat the different skin tones independently.

Yep. Also, the background and the hair tones are in the same shade of grey, so when I try to get the background less magenta the hair just changes together 
I'm also using Lumetri from Premiere for this and not Resolve. My fault, I can't expect very much from Lumetri. [Edit: I should just buy a 18% grey card already, I know]

Try doing a basic grade without a lut and see if you still get clipping.

I will.

+3 on mid-tones is quite extreme and yes, will likely cause some banding, especially if done after the lut. Why are you pushing mid-tones so much?

After your last reply I changed it a little, but I was doing it because the skin tones just get's too dark after applying (linear) contrast. I can just apply a general gain, but highlights will clip. I'm using a curve like this (you can see I'm quite agressive in the highlights):



If you have any pro tip for me, I take it

This is purely a subjective observation and you may actually be going for that look but I find the skin smoothing (possibly extreme noise reduction?) in 01.png to be way too much. It completely loses any texture in the skin and looks very unnatural. Try dialing back on the effects and you'll get a much better look

Thanks. Indeed, the noise reduction (NeatVideo) is way too strong.

Are you using Lumetri in Premier or After Effects?

Premiere Pro.


Thanks a lot for helping Andy, I'm learning very much these days...

[Andy600]

Yes, I suspected it was more complex than I thought.
MLVApp uses AlexaLog from this paper, it is indeed EI800. The ProRes color output is bt609 from ffmpeg. I think Premiere Pro reads it normally by default. The color matrix MLVApp is using came from ACR (actually you're credited in the source code for helping), so it's probably "precise" enough...

Do you know which ARRI lut you are using exactly? If you're unsure you can send me it or tell me the parameters you selected in the LUT generator and I'll check. If it's the full transform then there's your main problem. Your footage is in BT.601 or BT.709 (there's no bt609) and you are transforming it as if it were in a much wider gamut. This will not only cause over saturation but hue rotation because the primaries lay on a different axis and, because the gamut is a lot smaller than Alexa Wide Gamut, you're also likely losing some color information when rendering to Prores 'AlexaLog' in MLVApp.

The matrices are originally from Adobe. MLVApp looks to be writing a single matrix (D65) which should be ok for most daylight shots but white balance accuracy would be improved a bit if it also included the tungsten matrix.

Yep. Also, the background and the hair tones are in the same shade of grey, so when I try to get the background less magenta the hair just changes together 
I'm also using Lumetri from Premiere for this and not Resolve. My fault, I can't expect very much from Lumetri. [Edit: I should just buy a 18% grey card already, I know]

You can get decent results with Lumetri. Try using secondaries and, if necessary, multiple instances of Lumetri to isolate and grade problem parts of the image (after your primary grade).

I think the #1 piece of color related advice I would give is to always shoot a reference/target. A simple grey card can be very cheap and once you have that in shot you have a reference for exposure and white balance. I would say it's essential for any commercial shoot and most casual shooting really benefits from it.

After your last reply I changed it a little, but I was doing it because the skin tones just get's too dark after applying (linear) contrast. I can just apply a general gain, but highlights will clip. I'm using a curve like this (you can see I'm quite agressive in the highlights):



If you have any pro tip for me, I take it

Try adjusting the contrast pivot point lower if possible. Alternatively try increasing overall gain/exposure then pull down shadows and rolloff highlights i.e. a classic s-curve. This should give a more natural look.

Thanks. Indeed, the noise reduction (NeatVideo) is way too strong.

Yes. I have a rule with NR and that is to only use it if it's really necessary and then use as little as possible, limiting it to whichever channel(s) the noise is most apparent i.e. R,G,B or Luminance. Neatvideo is extremely good but is very easy to overcook if used as a broad stroke across everything. I also tend to limit sharpening to luminance or use highpass filtering on skin but that's always subjective.

Thanks a lot for helping Andy, I'm learning very much these days...

Your welcome I'll check out MLVApp's color when I get bit more free time.

[50mm1200s]

Do you know which ARRI lut you are using exactly?

It's the "AlexaV3_K1S1_LogC2Video_Rec709_EE_aftereffects3d". Parameters are Photometric Scaling, LUT Dimension 65^3 mesh and Bits set to default.

Your footage is in BT.601 or BT.709 (there's no bt609)...

haha, yeah.

The matrices are originally from Adobe. MLVApp looks to be writing a single matrix (D65) which should be ok for most daylight shots but white balance accuracy would be improved a bit if it also included the tungsten matrix.

If you mind, do you have any resource where we can get this matrice for tungsten?

I think the #1 piece of color related advice I would give is to always shoot a reference/target. A simple grey card can be very cheap and once you have that in shot you have a reference for exposure and white balance. I would say it's essential for any commercial shoot and most casual shooting really benefits from it.

Yes, I notice the need of grey cards now shooting RAW. With H.264, for 6 years, I never needed that, because I wasn't having such fine controls over the footage.

Try adjusting the contrast pivot point lower if possible. Alternatively try increasing overall gain/exposure then pull down shadows and rolloff highlights i.e. a classic s-curve. This should give a more natural look.

Cool. This technique of gain-then-curve is new to me.

Yes. I have a rule with NR and that is to only use it if it's really necessary and then use as little as possible...

I agree. Or, if necessary, use dithering/grain after NR.

Your welcome I'll check out MLVApp's color when I get bit more free time.

Trying to save you some time, here is the camera_matrices.c:

Code: [Select]

/* This may be the code I'm least proud of,
 * I know there is a simpler/better solution */

/* THIS IS NOT USED! I got lost and stopped at the point when I
 * realised some matrices were row-wise and others column-wise */

#include <stdio.h>
#include <stdint.h>
#include <string.h>

#include "video_mlv.h"
#include "raw.h"
#include "mlv.h"
#include "../matrix/matrix.h"

struct cam_matrices {
    char * camera;
    int32_t ColorMatrix1[18];
    int32_t ColorMatrix2[18];
    int32_t ForwardMatrix1[18];
    int32_t ForwardMatrix2[18];
};

static uint8_t diagonal_flip[9] = { 0, 3, 6, 1, 4, 7, 2, 5, 8 };
#define diag_flip(X) diagonal_flip[(X)]

/* credits to Andy600 for gleaning these from Adobe DNG converter */
static struct cam_matrices cam_matrices[] =
{
    { /* 0 */
        "Canon EOS 5D Mark III",
        { 7234, 10000, -1413, 10000, -600, 10000, -3631, 10000, 11150, 10000, 2850, 10000, -382, 10000, 1335, 10000, 6437, 10000 },
        { 6722, 10000, -635, 10000, -963, 10000, -4287, 10000, 12460, 10000, 2028, 10000, -908, 10000, 2162, 10000, 5668, 10000 },
        { 7868, 10000, 92, 10000, 1683, 10000, 2291, 10000, 8615, 10000, -906, 10000, 27, 10000, -4752, 10000, 12976, 10000 },
        { 7637, 10000, 805, 10000, 1201, 10000, 2649, 10000, 9179, 10000, -1828, 10000, 137, 10000, -2456, 10000, 10570, 10000 }
    },
    { /* 1 */
        "Canon EOS 5D Mark II",
        { 5309, 10000, -229, 10000, -336, 10000, -6241, 10000, 13265, 10000, 3337, 10000, -817, 10000, 1215, 10000, 6664, 10000 },
        { 4716, 10000, 603, 10000, -830, 10000, -7798, 10000, 15474, 10000, 2480, 10000, -1496, 10000, 1937, 10000, 6651, 10000 },
        { 8924, 10000, -1041, 10000, 1760, 10000, 4351, 10000, 6621, 10000, -972, 10000, 505, 10000, -1562, 10000, 9308, 10000 },
        { 8924, 10000, -1041, 10000, 1760, 10000, 4351, 10000, 6621, 10000, -972, 10000, 505, 10000, -1562, 10000, 9308, 10000 }
    },
    { /* 2 */
        "Canon EOS 7D",
        { 11620, 10000, -6350, 10000, 5, 10000, -2558, 10000, 10146, 10000, 2813, 10000, 24, 10000, 858, 10000, 6926, 10000 },
        { 6844, 10000, -996, 10000, -856, 10000, -3876, 10000, 11761, 10000, 2396, 10000, -593, 10000, 1772, 10000, 6198, 10000 },
        { 5445, 10000, 3536, 10000, 662, 10000, 1106, 10000, 10136, 10000, -1242, 10000, -374, 10000, -3559, 10000, 12184, 10000 },
        { 7415, 10000, 1533, 10000, 695, 10000, 2499, 10000, 9997, 10000, -2497, 10000, -22, 10000, -1933, 10000, 10207, 10000 }
    },
    { /* 3 */
        "Canon EOS 6D",
        { 7546, 10000, -1435, 10000, -929, 10000, -3846, 10000, 11488, 10000, 2692, 10000, -332, 10000, 1209, 10000, 6370, 10000 },
        { 7034, 10000, -804, 10000, -1014, 10000, -4420, 10000, 12564, 10000, 2058, 10000, -851, 10000, 1994, 10000, 5758, 10000 },
        { 7763, 10000, 65, 10000, 1815, 10000, 2364, 10000, 8351, 10000, -715, 10000, -59, 10000, -4228, 10000, 12538, 10000 },
        { 7464, 10000, 1044, 10000, 1135, 10000, 2648, 10000, 9173, 10000, -1820, 10000, 113, 10000, -2154, 10000, 10292, 10000 }
    },
    { /* 4 */
        "Canon EOS 70D",
        { 7546, 10000, -1435, 10000, -929, 10000, -3846, 10000, 11488, 10000, 2692, 10000, -332, 10000, 1209, 10000, 6370, 10000 },
        { 7034, 10000, -804, 10000, -1014, 10000, -4420, 10000, 12564, 10000, 2058, 10000, -851, 10000, 1994, 10000, 5758, 10000 },
        { 7763, 10000, 65, 10000, 1815, 10000, 2364, 10000, 8351, 10000, -715, 10000, -59, 10000, -4228, 10000, 12538, 10000 },
        { 7464, 10000, 1044, 10000, 1135, 10000, 2648, 10000, 9173, 10000, -1820, 10000, 113, 10000, -2154, 10000, 10292, 10000 }
    },
    { /* 5 */
        "Canon EOS 60D",
        { 7428, 10000, -1897, 10000, -491, 10000, -3505, 10000, 10963, 10000, 2929, 10000, -337, 10000, 1242, 10000, 6413, 10000 },
        { 6719, 10000, -994, 10000, -925, 10000, -4408, 10000, 12426, 10000, 2211, 10000, -887, 10000, 2129, 10000, 6051, 10000 },
        { 7550, 10000, 645, 10000, 1448, 10000, 2138, 10000, 8936, 10000, -1075, 10000, -5, 10000, -4306, 10000, 12562, 10000 },
        { 7286, 10000, 1385, 10000, 972, 10000, 2600, 10000, 9468, 10000, -2068, 10000, 93, 10000, -2268, 10000, 10426, 10000 }
    },
    { /* 6 */
        "Canon EOS 50D",
        { 5852, 10000, -578, 10000, -41, 10000, -4691, 10000, 11696, 10000, 3427, 10000, -886, 10000, 2323, 10000, 6879, 10000 },
        { 4920, 10000, 616, 10000, -593, 10000, -6493, 10000, 13964, 10000, 2784, 10000, -1774, 10000, 3178, 10000, 7005, 10000 },
        { 8716, 10000, -692, 10000, 1618, 10000, 3408, 10000, 8077, 10000, -1486, 10000, -13, 10000, -6583, 10000, 14847, 10000 },
        { 9485, 10000, -1150, 10000, 1308, 10000, 4313, 10000, 7807, 10000, -2120, 10000, 293, 10000, -2826, 10000, 10785, 10000 }
    },
    { /* 7 */
        "Canon EOS 550D",
        { 7755, 10000, -2449, 10000, -349, 10000, -3106, 10000, 10222, 10000, 3362, 10000, -156, 10000, 986, 10000, 6409, 10000 },
        { 6941, 10000, -1164, 10000, -857, 10000, -3825, 10000, 11597, 10000, 2534, 10000, -416, 10000, 1540, 10000, 6039, 10000 },
        { 7163, 10000, 1301, 10000, 1179, 10000, 1926, 10000, 9543, 10000, -1469, 10000, -278, 10000, -3830, 10000, 12359, 10000 },
        { 7239, 10000, 1838, 10000, 566, 10000, 2467, 10000, 10246, 10000, -2713, 10000, -112, 10000, -1754, 10000, 10117, 10000 }
       
    },
    { /* 8 */
        "Canon EOS 600D",
        { 7164, 10000, -1916, 10000, -431, 10000, -3361, 10000, 10600, 10000, 3200, 10000, -272, 10000, 1058, 10000, 6442, 10000 },
        { 6461, 10000, -907, 10000, -882, 10000, -4300, 10000, 12184, 10000, 2378, 10000, -819, 10000, 1944, 10000, 5931, 10000 },
        { 7486, 10000, 835, 10000, 1322, 10000, 2099, 10000, 9147, 10000, -1245, 10000, -12, 10000, -3822, 10000, 12085, 10000 },
        { 7359, 10000, 1365, 10000, 918, 10000, 2610, 10000, 9687, 10000, -2297, 10000, 98, 10000, -2155, 10000, 10309, 10000 }
       
    },
    { /* 9 */
        "Canon EOS 650D",
        { 6985, 10000, -1611, 10000, -397, 10000, -3596, 10000, 10749, 10000, 3295, 10000, -349, 10000, 1136, 10000, 6512, 10000 },
        { 6602, 10000, -841, 10000, -939, 10000, -4472, 10000, 12458, 10000, 2247, 10000, -975, 10000, 2039, 10000, 6148, 10000 },
        { 7747, 10000, 485, 10000, 1411, 10000, 2340, 10000, 8840, 10000, -1180, 10000, 105, 10000, -4147, 10000, 12293, 10000 },
        { 7397, 10000, 1199, 10000, 1047, 10000, 2650, 10000, 9355, 10000, -2005, 10000, 193, 10000, -2113, 10000, 10171, 10000 }
       
    },
    { /* 10 */
        "Canon EOS 700D",
        { 6985, 10000, -1611, 10000, -397, 10000, -3596, 10000, 10749, 10000, 3295, 10000, -349, 10000, 1136, 10000, 6512, 10000 },
        { 6602, 10000, -841, 10000, -939, 10000, -4472, 10000, 12458, 10000, 2247, 10000, -975, 10000, 2039, 10000, 6148, 10000 },
        { 7747, 10000, 485, 10000, 1411, 10000, 2340, 10000, 8840, 10000, -1180, 10000, 105, 10000, -4147, 10000, 12293, 10000 },
        { 7397, 10000, 1199, 10000, 1047, 10000, 2650, 10000, 9355, 10000, -2005, 10000, 193, 10000, -2113, 10000, 10171, 10000 }
       
    },
    { /* 11 */
        "Canon EOS 1100D",
        { 6873, 10000, -1696, 10000, -529, 10000, -3659, 10000, 10795, 10000, 3313, 10000, -362, 10000, 1165, 10000, 7234, 10000 },
        { 6444, 10000, -904, 10000, -893, 10000, -4563, 10000, 12308, 10000, 2535, 10000, -903, 10000, 2016, 10000, 6728, 10000 },
        { 7607, 10000, 647, 10000, 1389, 10000, 2337, 10000, 8876, 10000, -1213, 10000, 93, 10000, -3625, 10000, 11783, 10000 },
        { 7357, 10000, 1377, 10000, 909, 10000, 2729, 10000, 9630, 10000, -2359, 10000, 104, 10000, -1940, 10000, 10087, 10000 }
       
    },
    { /* 12 */
        "Canon EOS M",
        { 6985, 10000, -1611, 10000, -397, 10000, -3596, 10000, 10749, 10000, 3295, 10000, -349, 10000, 1136, 10000, 6512, 10000 },
        { 6602, 10000, -841, 10000, -939, 10000, -4472, 10000, 12458, 10000, 2247, 10000, -975, 10000, 2039, 10000, 6148, 10000 },
        { 7747, 10000, 485, 10000, 1411, 10000, 2340, 10000, 8840, 10000, -1180, 10000, 105, 10000, -4147, 10000, 12293, 10000 },
        { 7397, 10000, 1199, 10000, 1047, 10000, 2650, 10000, 9355, 10000, -2005, 10000, 193, 10000, -2113, 10000, 10171, 10000 }
    }
};

/* Matrices from DXO */
double matrix_5d2[9] = {  2.25, -1.50,  0.25,
                         -0.26,  1.62, -0.36,
                         -0.04, -0.40,  1.43  };


static const double xyz_to_rgb[] = {
    3.240710, -0.9692580,  0.0556352,
   -1.537260,  1.8759900, -0.2039960,
   -0.498571,  0.0415557,  1.0570700
};


/* Provides a DXO matrix from camera space to sRGB */
void getMlvCameraTosRGBMatrix(mlvObject_t * video, double * outputMatrix)
{
    double camera_matrix[9] = {1, 0, 0, 0, 1, 0, 0, 0, 1};
    int32_t * original_matrix;
    uint8_t * camera_name = video->IDNT.cameraName;

    /* Identify camera */
    if (camera_name[10] == '5')
    {
        /* it is either 5D or 50D or 500D or 550D... */
        if (camera_name[11] == 'D')
        {
            /* It is 5D II or III */
            if (camera_name[20] == 'I')
            {
                /* 5D Mark III */
                original_matrix = cam_matrices[0].ColorMatrix2;
            }
            else
            {
                /* 5D Mark II */
                // original_matrix = matrix_5d2;
            }
        }
        else if (camera_name[11] == '0')
        {
            /* It is 50D or 500D */
            if (camera_name[12] == '0')
            {
                /* Is 500D - we use 550d matrix as I don't see 500D */
                original_matrix = cam_matrices[7].ColorMatrix2;
            }
            else
            {
                /* Is 50D */
                original_matrix = cam_matrices[6].ColorMatrix2;
            }
        }
        else
        {
            /* It is 550D! */
            original_matrix = cam_matrices[7].ColorMatrix2;
        }
    }
    else if (camera_name[10] == '6')
    {
        /* It is 6D or 60D or 600D or 650D */
        if (camera_name[11] == 'D')
        {
            /* It is 6D */
            original_matrix = cam_matrices[3].ColorMatrix2;
        }
        else if (camera_name[11] == '0')
        {
            /* Is 60D or 600D */
            if (camera_name[12] == 'D')
            {
                /* It is 60D */
                original_matrix = cam_matrices[5].ColorMatrix2;
            }
            else
            {
                /* It is 600D */
                original_matrix = cam_matrices[8].ColorMatrix2;
            }
        }
        else
        {
            /* It is 650D */
            original_matrix = cam_matrices[9].ColorMatrix2;
        }
    }
    else if (camera_name[10] == '7')
    {
        /* It is 7D or 70D or 700D */
        if (camera_name[11] == 'D')
        {
            /* It is 7D */
            original_matrix = cam_matrices[2].ColorMatrix2;
        }
        else if (camera_name[12] == 'D')
        {
            /* It is 70D */
            original_matrix = cam_matrices[4].ColorMatrix2;
        }
        else
        {
            /* It is 700D; 650D matrix will do right? */
            original_matrix = cam_matrices[9].ColorMatrix2;
        }
    }
    else if (camera_name[10] == '1')
    {
        /* 100D or 1100D (and 1200-16900D) */
        if (camera_name[11] == '1')
        {
            /* It is 1100D */
            original_matrix = cam_matrices[11].ColorMatrix2;
        }
        else if (camera_name[11] == '0')
        {
            /* Is 100D, hopefully 650D matrix will do */
            original_matrix = cam_matrices[9].ColorMatrix2;
        }
        else
        {
            //TODO: Ilia, please fix: in this case original_matrix is uninitialized
        }
    }
    else if (camera_name[10] == 'M')
    {
        /* Is EOS M */
        original_matrix = cam_matrices[12].ColorMatrix2;
    }
    /* As a backup, just do 650D */
    else
    {
        original_matrix = cam_matrices[9].ColorMatrix2;
    }

    /* Convert the silly integere matrix to floaty point */
    matrixRemoveDividers(original_matrix, camera_matrix);

    double out[9];
    invertMatrix(matrix_5d2, out);

    /* giv */
    for (int i = 0; i < 9; ++i)
    {
        outputMatrix[i] = out[i];
    }
}



WB matrix:

Code: [Select]

/* Measurements taken from 5D Mark II RAW photos using EXIFtool, surely Canon can't be wrong about WB mutipliers? */
static const int wb_kelvin[]   = {  2000,  2500,  3000,  3506,  4000,  4503,  5011,  5517,  6018,  6509,  7040,  7528,  8056,  8534,  9032,  9531, 10000 };
static const double wb_red[]   = { 1.134, 1.349, 1.596, 1.731, 1.806, 1.954, 2.081, 2.197, 2.291, 2.365, 2.444, 2.485, 2.528, 2.566, 2.612, 2.660, 2.702 };
static const double wb_green[] = { 1.155, 1.137, 1.112, 1.056, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000, 1.000 };
static const double wb_blue[] = { 4.587, 3.985, 3.184, 2.524, 2.103, 1.903, 1.760, 1.641, 1.542, 1.476, 1.414, 1.390, 1.363, 1.333, 1.296, 1.263, 1.229 };

AlexaLog:

Code: [Select]

/* Calculate Alexa Log curve (iso 800 version), from here: http://www.vocas.nl/webfm_send/964 */
double AlexaLogCTonemap(double x) { return (x > 0.010591) ? (0.247190 * log10(5.555556 * x + 0.052272) + 0.385537) : (5.367655 * x + 0.092809); }
float AlexaLogCTonemap_f(float x) { return (x > 0.010591f) ? (0.247190f * log10f(5.555556f * x + 0.052272f) + 0.385537f) : (5.367655f * x + 0.092809f); }

There's also this:

Code: [Select]

#ifndef _image_profile_h_
#define _image_profile_h_

/* Image profile structure */
typedef struct image_profile_t {
    /* Certain processing settings can be disabled for accuracy (1=on, 0=off) */
    struct disable_settings {
        int saturation; /* Saturation */
        int curves; /* All contrast + 'lighten' setting */
        int tonemapping; /* Tonemapping, via specified function */
    } disable_settings;
    /* Tonemapping function pointer, required if tonemapping is not disabled
     * this function can be any kind of transform for 0.0-1.0 double values */
    double (* tone_mapping_function)(double);
    double gamma_power; /* 1.0=linear/do nothing, 2.2~=sRGB, 2.0=rec.709 */
    /* xy chromaticities for output colour space */
    struct xy_chromaticity {
        struct { int x, y; } red;
        struct { int x, y; } green;
        struct { int x, y; } blue;
        struct { int x, y; } white;
    } xy_chromaticity;
    /* https://ninedegreesbelow.com/photography/xyz-rgb.html
     * http://www.ryanjuckett.com/programming/rgb-color-space-conversion/ */
}  image_profile_t;

#endif



I just don't know how it assign each matrix. Through MLV metadata? I've found mlv metadata not to be so reliable (in the past... don't know if anything changed in past year).

[Andy600]

It's the "AlexaV3_K1S1_LogC2Video_Rec709_EE_aftereffects3d". Parameters are Photometric Scaling, LUT Dimension 65^3 mesh and Bits set to default.

Does it include a colorspace conversion?

If you mind, do you have any resource where we can get this matrice for tungsten?

It's in the camera_matrices.c you posted (the second rows of each set are the Tungsten/StdA matrices)

Trying to save you some time, here is the camera_matrices.c:

Ok after a very quick look through  it looks as though the full set of Adobe matrix coefficients are there (in camera_matrices.c) but only the second matrix (D65) is assigned. It also shows a Dx0 matrix for the 5D2 (is this used for everything?). The Adobe DNG SDK has everything needed for raw color all in one place so it escapes me why devs continue to cherrypick non-standard info from the internet. It must be a coding thing!?

Another pet peev of mine is XYZ colorspace being assumed to have a D65 whitepoint (as with that xyz2rgb matrix). XYZ colorspace, as referred to in Adobe DNGs and ICC profiles and most apps built on ICC, has a D50 white point and all the math uses D50 with chromatic adaptation where necessary to change the white point. You have to be very careful to not mix up D50 and D65 matrix math or you will get the wrong colors. I'm not saying that's what's happening here but there is a mixture of methods in use and I would have to pick through the code to see how it's working.

I just don't know how it assign each matrix. Through MLV metadata? I've found mlv metadata not to be so reliable (in the past... don't know if anything changed in past year).

You could add it manually with Exiftool, override it with a DNG profile in ACR or ask the dev to enable it. The actual difference to color is usually very small (but can be more with certain lighting) but the second matrix is preferable for white balancing non-daylight sources (as with your footage for example).

The Log-C math looks correct but where and when does it get applied? Is it in float or int and before/after colorspace is assigned. This can all make a difference. AlexaLog should match Log-C in other apps (at least the gamma part because MLVApp is limited to sRGB primaries from what I can tell).

The white balance multipliers are Canon's and wouldn't be relevant to DNGs if the app utilized the SDK. Adobe's white balancing is IMO far superior and more importantly, neutral but it's a bit more complicated to implement.

[bouncyball]

It's in the camera_matrices.c you posted (the second rows of each set are the Tungsten/StdA matrices)

Ok after a very quick look through  it looks as though the full set of Adobe matrix coefficients are there (in camera_matrices.c) but only the second matrix (D65) is assigned. It also shows a Dx0 matrix for the 5D2 (is this used for everything?). The Adobe DNG SDK has everything needed for raw color all in one place so it escapes me why devs continue to cherrypick non-standard info from the internet. It must be a coding thing!?

'camera_matrices.c' was long time deprecated. Also only 5D2 matrix is used in master branch for all cameras.

This is the file which is used by WhiteBalance branch now. All matrixes for all ML supported cameras there (2 color matrixes and 2 forward matrixes) are from Adobe.

However Ilia is experimenting a lot with this branch and there is some problem with multiplier deriving function which is not working properly for temps lower then 4000K.

regards
bb

[ilia3101]

Oh wow all the code on her makes MLV App colour management look horrific It's a bit better than all of the unused code makes it look (well, in the whitebalance branch at least)

@Andy600 I have been wondering for a very long time, is ColorMatrix2 D65 white point? I have assumed this, and it seems to match(??), but not tested it with actual comparison. If you could tell me definitely if it is D65 or D50, that would make me quite satisfied. These are adobe matrices I think (is this right bouncyball?)

[50mm1200s]

'camera_matrices.c' was long time deprecated. Also only 5D2 matrix is used in master branch for all cameras.

My bad for linking wrong info.

is not working properly for temps lower then 4000K.

This is probably the issue I'm having then, since my footage is ~3700K...

[masc]

This is probably the issue I'm having then, since my footage is ~3700K...

Did you compile and use the Whitebalance branch, bouncyball was talking about? The master branch works good also for 3000K (maybe also less, but I never used that), at least for 5D2 clips.

[50mm1200s]

Did you compile and use the Whitebalance branch, bouncyball was talking about? The master branch works good also for 3000K (maybe also less, but I never used that), at least for 5D2 clips.

Eh, I think I need to learn english better before discussing image processing on a forum   
I'm using release binary, haven't compiled (yet).

[Andy600]

@Andy600 I have been wondering for a very long time, is ColorMatrix2 D65 white point? I have assumed this, and it seems to match(??), but not tested it with actual comparison. If you could tell me definitely if it is D65 or D50, that would make me quite satisfied. These are adobe matrices I think (is this right bouncyball?)

No. It's not that simple unfortunately. Technically speaking it's D50 but would be observed as green on a display because of the bayer pattern.

The color matrices describe a transform from XYZ (D50) to non-white balanced camera RGB. The D65 part only references how the color calibration was performed i.e. D65 is a calibration under a daylight illuminant (~6504K) and Standard A is under a tungsten illuminant (~2856k). The sensor behaves differently depending on the spectral power distribution of the light source hence why it's a good idea to have 2 calibrations under different temperatures.

[ilia3101]

@Andy600 Thanks for the explanations. So ColorMatrix2, when inverted, describes a transform from "CameraRGB" (debayered) to XYZ with D50 white point.(?)

So... when that image in XYZ is transformed to sRGB (for viewing) it will be the same as having the white balance slider set to ~5000k in a raw converter and looking at it?

And it makes a lot of sense that the sensor would respond differently at lower colour temperature, never thought about that before. But I'm a little confused as to what the temperature of ColorMatrix1 (the ones we have in ML code) is... where do I find out?

[Andy600]

Edit: Sorry, this may be counter intuitive to my earlier reply but to clarify*:

@Andy600 Thanks for the explanations. So ColorMatrix2, when inverted, describes a transform from "CameraRGB" (debayered) to XYZ with D50 white point.(?)

Not exactly. A CIE white point isn't yet assigned but you can theoretically assume it is (or later will be) D65 white because the temperature of the illuminant under which the calibration is taken/made is ~6500K. DNG math works in XYZ space (CIE D50 white or little x 0.3456 little y 0.3585 big Y 1.0000) so the color matrices need adapting to D50 to make DNG WB math work. CameraRGB doesn't have a defined white point other than what the calibration illuminant dictates, there is a point in the matrix where R,G and B would = 1 so this is used as white.

So... when that image in XYZ is transformed to sRGB (for viewing) it will be the same as having the white balance slider set to ~5000K in a raw converter and looking at it?

That depends entirely on the raw converter and how it calculates/interprets white balance. CameraRGB is not itself neutral and you will be viewing it on a monitor, likely to be using a D65 white point (so the wp should have been adapted for it) and there are white balance multipliers to factor into it which control the slider so the app slider should reflect the as shot color temp (there will likely be a difference in what the WB is interpreted and displayed as depending on which method of white balancing the app uses).

And it makes a lot of sense that the sensor would respond differently at lower colour temperature, never thought about that before. But I'm a little confused as to what the temperature of ColorMatrix1 (the ones we have in ML code) is... where do I find out?

ColorMatrix 1 is ~2850K (the approximate temperature of an old school tungsten filament incandescent light bulb). AKA CIE Standard Illuminant A

for how DNG works look in the Adobe DNG SDK

(*Might have to clarify some of this further as it's from memory. I need to refer to my notes to be sure )