[In Progress] ML ISO in photo mode.

[ItsMeLenny]

Could ML ISO be enabled in photo mode? (550D)
I'm assuming it's disabled there because it doesn't effect raw.
But for those who like to shoot jpeg. (<-just me probably)

[Audionut]

Have a good read through the ADTG thread.  a1ex dropped some hints about what registers do what, raw vs jpg for instance.

It will be good practice for finding those curve registers 

Otherwise, just wait for ADTG gains to be polished and published.  I can pull ISO 200 to ISO 145 for instance.

[ItsMeLenny]

Oh my bad, I thought that was slightly different.
I thought ML iso in picture was just never enabled.
And then that ADTG thread got me thinking about it.

[a1ex]

finding those curve registers 

If you are talking about picture style, the contrast curve is at c0f0f100 ... c0f0160. The hard part is understanding the meaning of each register. These registers can't be read, you can only write to them and observe the effect. Also, they work only on DIGIC 4.

[ItsMeLenny]

If you are talking about picture style, the contrast curve is at c0f0f100 ... c0f0160. The hard part is understanding the meaning of each register. These registers can't be read, you can only write to them and observe the effect. Also, they work only on DIGIC 4.

Is that the picture style contrast curve, or is that the camera base curve. The latter I believe being able to be changed on the 5d to 3 custom options. The picture style curve being the one burnt into the picture style.
Picture Style Editor only allows for the first to be changed in it's PF2 format, but it then also implemented base curve into PF3, which I believe works on all (most?) cameras.


(Took me a bit to find this in the maze: http://magiclantern.wikia.com/wiki/Register_Map/Brute_Force/C0F0Fxxx ) [for anyone else reading along]

[a1ex]

Yeah, the picture style contrast curve. Lock down these registers to some value, change picture style and contrast, and all stays the same.

For example, this sets luma to 128 everywhere:

Code: [Select]

            for (uint32_t reg = 0xc0f0f100; reg <= 0xc0f0f160; reg += 4)
                EngDrvOutLV(reg, 0);
            EngDrvOutLV(0xc0f0f11c, 128);
            EngDrvOutLV(0xc0f0f128, 128);
            EngDrvOutLV(0xc0f0f134, 128);
            EngDrvOutLV(0xc0f0f150, 128);
            EngDrvOutLV(0xc0f0f160, 128);

copied from lv-img-engio.c (so if anyone wants to experiment, start tweaking this code)

[ItsMeLenny]

Yeah, the picture style contrast curve. Lock down these registers to some value, change picture style and contrast, and all stays the same.

For example, this sets luma to 128 everywhere:
....

I haven't tried these out yet, but I think they would be the tone curve, not the picture style curve, because if it stays across all picture styles than it's not built into the picture style. Where as the tone curve (or base curve?) is changeable on some higher end cameras (including default and 3 user defined), and I'm under the impression lower end cameras have the feature also but locked away.
Both would be good to have control of, but the tone curve would mean it's a curve on top of the picture style curve. (Which also, using pf3 allows for tone curved in picture styles also, rather than the old pf2 format).


Only the "specific colors" panel is saved using pf2, including the curve. Where as to save changes all 3 panels, "basic" "six color axis" and "specific colors, one has to use the pf3 extension.
The six color axis panel may explain what's going on in registers such as "C0F0F1B0" and "C0F0F3C4" and similar (the latter is questioned to be a bool, although the picture style editor allows for a range of de-saturation).

[a1ex]

It stays the same because you have overriden it.

[ItsMeLenny]

It stays the same because you have overriden it.

Oh. I thought as soon as you change picture style though that canon would override your override.

[ItsMeLenny]

Yeah, the picture style contrast curve. Lock down these registers to some value, change picture style and contrast, and all stays the same.

For example, this sets luma to 128 everywhere:

Code: [Select]

            for (uint32_t reg = 0xc0f0f100; reg <= 0xc0f0f160; reg += 4)
                EngDrvOutLV(reg, 0);
            EngDrvOutLV(0xc0f0f11c, 128);
            EngDrvOutLV(0xc0f0f128, 128);
            EngDrvOutLV(0xc0f0f134, 128);
            EngDrvOutLV(0xc0f0f150, 128);
            EngDrvOutLV(0xc0f0f160, 128);

copied from lv-img-engio.c (so if anyone wants to experiment, start tweaking this code)

Just tried modifying these registers. (Also first time modifying ML source and compiling *takes a bow*)
For starters, I think these are not the right registers, these do something really bizarre.
Also, those 128 should actually be 127.
I set my test up as;

Code: [Select]

            for (uint32_t reg = 0xc0f0f100; reg <= 0xc0f0f160; reg += 4)
                EngDrvOutLV(reg, 0);
            EngDrvOutLV(0xc0f0f11c, 0);
            EngDrvOutLV(0xc0f0f128, 64);
            EngDrvOutLV(0xc0f0f134, 127);
            EngDrvOutLV(0xc0f0f150, 191);
            EngDrvOutLV(0xc0f0f160, 255);
And it created some quite funky effects, a more appealing cartoon effect actually.
Also made things very contrasty. Only effected video recording, doesn't effect photos (probably already known but I am looking for something that effects both video and jpegs). So which also suggests that those aren't picture style registers.
But as for it being used to modify the curve, they can't be.

[a1ex]

Yes, they are. That code is only for LiveView, so... of course it only affects videos.

However, their exact meaning is almost impossible to understand. Only the ones I've set to 128 are actually luma; the others seem to be some sort of polynomial coefficients.

For photo, you might (or might not!) have some luck by following this thread: www.magiclantern.fm/forum/index.php?topic=1915

BTW, some fun stuff with picture styles with the latest raw_diag (from the ADTG/CMOS ISO thread):



I guess these graphs might be useful for picture style authors (although it's probably very easy to get them with some existing software). Here, you can alter these parameters one by one and plot the curves, but the hardest part is to guess Canon's default values so you can start from there.

Now it should be obvious why YUV-based clipping warnings may give false positives roughly 1 stop before the actual clipping occurs in RAW.

Also... neutral -4 is more linear than I thought.

P.S. to get nice graphs, make sure you have the same color throughout your image. It's simply a dumb plot of Y (from YUV) vs RAW value (red, green or blue channel).

[ItsMeLenny]

Here's some of my tests done using the spotmeter and pointing my camera at a bright light. Not the most accurate way, but it gives some indication of the curves.


The above shows neutral vs VideoX with all their settings at default.


The above shows neutral -4 contrast vs neutral +4 contrast against a linear and a gamma curve of 2.0 (or inverse of 0.5)


And this one is an old one that shows neutral vs neutral HTP vs neutral -4 contrast.

HOWEVER; despite what appears like closer linearity of the picture styles with -4 contrast, it still cuts off dynamic range.

Heres not the greatest examples because there is no high lights in this picture, but you can see what goes on with the lowlights.
The first -4 contrast, the 2nd a 0.5 gamma curve.

[ItsMeLenny]

A better example of pictures, or rather an example of what happens to the highlights of canons picture styles compared to the previous photos which were more lowlights.
The first -4 contrast on neutral, the 2nd a 0.5 gamma curve. (and I'll include the above pictures as well for extra side by side

-4 Contrast | Neutral Picture Style	0.5 Inverse Gamma | UFRaw