Canon 1100D / T3

Started by a1ex, June 14, 2012, 04:50:54 PM

Previous topic - Next topic

0 Members and 5 Guests are viewing this topic.

nanomad

Just don't use ETTR in LV.. We will figure out a way to block it
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

dmilligan

Quote from: a1ex on February 01, 2014, 08:29:05 AM
I believe all you have to do is:
a) return 0 from can_use_raw_overlays_menu() on the LiveView photo branch if there's no CONFIG_RAW_LIVEVIEW.
b) add a meaningful message in menu_set_warning_raw (like raw is not working in LiveView on this camera).

This code will be used whenever there's something that requires raw support (assumming it calls menu_checkdep_raw from its MENU_UPDATE_FUNC).

The problems is more complicated than this and will require more significant refactoring to make the menu items logical in the situation that raw is not available in LV. Basically all the menu items are currently setup to assume that if raw is available at all, it is available in LV. We have the 1100D where this is not the case, and the menu items are extremely confusing even if I just add a warning here.

Here's what I mean:
The Histogram menu item will say:
Histogram       RAW RGB, Log, Dots

Even if I'm in LV where the histogram is not RAW, it is RAW during QR, so which histogram are we talking about? One of the histograms will be RAW and one won't. How do we convey this logically to the user? We can't say RAW histogram isn't working, it is working, sometimes...

I think this merits a complete rethink of the entire Overlay menu. Maybe there should be three separate overlay configurations: Movie, LV, and QR (maybe even a 4th MovieRaw). Currently the Overlay menu is very nonsensical for anyone who is not extremely familiar with how it works, in terms of what settings apply in what particular situations.

I also don't think there's any particular reason to even give the user the choice of what type (RAW vs. YUV) of overlay to use. The particular situation totally determines the type that should be used:
h264? - always use YUV overlays
raw_rec/mlv? - always use raw overlays
photo?
  picture_quality_raw? - use raw if available, otherwise warn that YUV is being used instead
  picture_qualtiy_jpeg? - always use YUV

thoughts?

a1ex

Will answer after you try it.

dmilligan

Quote from: a1ex on February 01, 2014, 11:21:55 PM
Will answer after you try it.
I did:

--- a/src/raw.c
+++ b/src/raw.c
@@ -1690,6 +1690,13 @@

MENU_UPDATE_FUNC(menu_checkdep_raw)
{
+#ifndef CONFIG_RAW_LIVEVIEW
+    if(lv)
+    {
+        MENU_SET_WARNING(MENU_WARN_NOT_WORKING,"RAW LV is not working on this camera");
+    }
+    else
+#endif
     if (!can_use_raw_overlays_menu())
     {
         menu_set_warning_raw(entry, info);


it's still quite confusing

a1ex

Did you try to do like I said here?
Quote
a) return 0 from can_use_raw_overlays_menu() on the LiveView photo branch if there's no CONFIG_RAW_LIVEVIEW.
b) add a meaningful message in menu_set_warning_raw (like raw is not working in LiveView on this camera).

dmilligan

The logic is extremely confusing due to all the macros (sometimes I think ML could win http://www.ioccc.org) :P

is this what you mean?

diff --git a/src/raw.c b/src/raw.c
--- a/src/raw.c
+++ b/src/raw.c
@@ -1662,13 +1662,11 @@
             return 1;
     }
     else
-#endif
     {
         /* outside LiveView: only pure RAW is known to work */
         if (can_use_raw_overlays_photo())
             return 1;

-#ifdef CONFIG_RAW_LIVEVIEW
         /* in LiveView: we can display the raw overlays no matter what */
         /* so use them also for sRAW and mRAW, even if this may not work in QR mode */
         int raw = pic_quality & 0x60000;
@@ -1682,10 +1680,19 @@

MENU_UPDATE_FUNC(menu_set_warning_raw)
{
-    MENU_SET_WARNING(MENU_WARN_NOT_WORKING,
-        is_movie_mode() ? "[MOVIE] This feature requires you shooting RAW." :
-                          "[PHOTO] Set picture quality to RAW in Canon menu."
-    );
+#ifndef CONFIG_RAW_LIVEVIEW
+    if(lv)
+    {
+        MENU_SET_WARNING(MENU_WARN_NOT_WORKING,"RAW LV is not working on this camera");
+    }
+    else
+#endif
+    {
+        MENU_SET_WARNING(MENU_WARN_NOT_WORKING,
+                         is_movie_mode() ? "[MOVIE] This feature requires you shooting RAW." :
+                         "[PHOTO] Set picture quality to RAW in Canon menu."
+                         );
+    }
}

MENU_UPDATE_FUNC(menu_checkdep_raw)

a1ex

Looks like Nano did half of the job, so it should work as I expect it to (which is basically exactly as you described).

So, in LiveView, histogram should print RAW only if the LiveView histogram is RAW. In photo mode, it should print RAW only if the QR histogram is RAW.

And this is auto-chosen based on picture quality.

Movie:
- H264 => YUV histogram.
- Some sort of raw recording => RAW histogram.

Photo:
- in LiveView, if pic quality is set to some sort of RAW => RAW histogram (if there is backend support), otherwise YUV
- in QR, if pic qualty is set to pure RAW (the only setting that works on all cameras), you get RAW overlays

So, with default settings, it tries to use RAW overlays whenever it makes sense. Try them on 60D, it should work like this.

The option for zebra (photo vs always) is there for speed reasons. Raw zebras are slow.

Adding a bunch of new menus doesn't sound like simplifying things to me.

dmilligan

Quote from: nanomad on February 01, 2014, 12:11:05 PM
Just don't use ETTR in LV.. We will figure out a way to block it
would this work? not sure if it will screw something else up (why is raw_lv_is_enabled() currently only checked for movie mode?):

diff --git a/modules/ettr/ettr.c b/modules/ettr/ettr.c
--- a/modules/ettr/ettr.c
+++ b/modules/ettr/ettr.c
@@ -728,7 +728,7 @@
     if (lens_info.raw_iso == 0 && is_m) return 0;
     if (lens_info.raw_shutter == 0 && is_m) return 0;
     if (HDR_ENABLED && !AUTO_ETTR_TRIGGER_BY_SET) return 0;
-    int raw = is_movie_mode() ? raw_lv_is_enabled() : pic_quality & 0x60000;
+    int raw = raw_lv_is_enabled() && (is_movie_mode() || pic_quality & 0x60000);
     return raw;
}

dmilligan

Quote from: a1ex on February 02, 2014, 12:43:00 AM
Adding a bunch of new menus doesn't sound like simplifying things to me.
what I have in mind should make the menu simpler, I'll try and code something up so you'll have a better idea of what I mean

a1ex

With global draw off for example, it won't work (because it won't be able to request the raw mode - it will give up before trying).

Hiding the option from the menu should be enough (only show auto snap and always on).

dmilligan

in 'always on' ettr still tries to run when you enter LV (and completely screws all the settings) even if raw data is not available, that is the bug. there's no separate option for 'only after you take a pic'. so basically until this is fixed you can't use ettr for QR and still use LV, i.e. I should still be able to use LV and have ettr work from QR data after the pic is taken, but I can't because ettr still tries to run

dmilligan

perhaps this is the problem

    raw_lv_request();
    int corr = auto_ettr_get_correction();
    raw_lv_release();


the return value of raw_lv_request() is not actually checked by ettr

should it be:

    if(!raw_lv_request()) return;
    int corr = auto_ettr_get_correction();
    raw_lv_release();


EDIT: okay, I now realize that is void function so that won't work

a1ex

Correct, good catch.

You could even disable it completely in auto_ettr_polling_cbr: if (raw_lv_request == ret_0) return.

dmilligan

Quote from: a1ex on February 02, 2014, 09:38:13 PM
Correct, good catch.

You could even disable it completely in auto_ettr_polling_cbr: if (raw_lv_request == ret_0) return.
brilliant, that was what I was really looking for: check if the WEAK_FUNC is actually weak

dmilligan

okay, so 'raw_lv_request == ret_0' gives a compiler warning and doesn't actually work (ettr is still trying to run), this is used elsewhere to give menu warnings, and the warning don't work either

nanomad

Weird they do work here...
EOS 1100D | EOS 650 (No, I didn't forget the D) | Ye Olde Canon EF Lenses ('87): 50 f/1.8 - 28 f/2.8 - 70-210 f/4 | EF-S 18-55 f/3.5-5.6 | Metz 36 AF-5

dmilligan

well, now it works, that's weird... there's still a compiler warning though, maybe there is a more 'correct' way to do this, but I don't know, I'm not familiar with the specifics of weak functions in C

a1ex

How this works: you are comparing two function pointers. You get the warning because the two functions have different prototypes, but since ret_0 does nothing, there are no side effects. The ABI takes care about compatibility.

You could cast the two pointers to thunk or void* or intptr_t for example, to get rid of the warning.

I'm tempted to write "if (&raw_lv_request == &ret_0)". It's the same thing for some historical reasons, but I feel it's a little more explicit (it's more obvious that you are comparing two function pointers).

dmilligan

I'd agree &raw_lv_request == &ret_0 seems more correct at least to me (I actually have to write some in C89 at work and this would be the syntax I'm used to), but when I tried it, it gave the same warning, so I wasn't sure what was going on. I didn't realize the functions had different prototypes. I guess then the most correct thing to do would be define a ret_void and use that instead of ret_0 or make raw_lv_request return something.

(I was actually more curios how the 'weak' stuff is implemented. How does it actually switch the symbol references dynamically like that, it's pretty cool and I didn't realize you could do it in C. I've done similar stuff but only in higher level languages)


a1ex

Quick question: does motion detect with frame difference work on 1100D?

fufuheo

No, it says Motion level=0 even when moving the camera a lot. I am not able to get it to react at all
1100D, EOSM, EF-M 18-55 IS STM EF 75-300 f/4-5.6 II USM, EF 50mm f/1.8

a1ex

Got it, having the same problem on 5D3 123 and I bet on the 6D it doesn't work either.

iDoggie

Whenever i try to install the nightly build it says that FONTS.DAT not found?

EDIT: solved..

iDoggie

One question though.. is it possible to take double exposures with the current Magic Lantern?

47Crows

Quote from: iDoggie on February 07, 2014, 02:45:52 AM
One question though.. is it possible to take double exposures with the current Magic Lantern?

Nope, and from what I recall, it won't be possible in any version (unless someone makes a separated script/module) because it's something you can do in post.