eoszoomposition scale wrong

[anjok]

Describe the bug
Apparently the eoszoomposition position uses a wrong scale. It should use the full width/height of the sencor and not the viewfinder rect. When you set eoszoom to, say, 5, you can only cover about a 10th or so when moving the scroll widgets.

So the allowed values should be 0...sensorsize-viewfindersize and not 0... viewfindersize

To Reproduce
Exact steps to reproduce the behavior.

1. Connect to a Canon camera (I tried 6D and 450)
2. Open Stream
3. Choose a zoom factor (say 5)
4. scroll around with the widgets on top of the steaming window

Expected behavior
You should be able to cover the whole area of the viewfinder, but you can only see about a 4th of it, as the eoszoomposition property is only between 0...viewfindersize and not 0...sensorsize.

You can verify that it works in theory when you input different, higher values into the INDI field. Say 3000,1500 and watch the back of the camera, too. You are able to cover the full range of the sensor by manually inputing values, but that's pretty cumbersome.

This is pretty annoying as you should be able to focus pretty fast with a bathinov mask and the highest maginfication.

[anjok]

This here is an extremely lazy fix which nonetheless works:

diff --git a/indi-gphoto/gphoto_ccd.cpp b/indi-gphoto/gphoto_ccd.cpp
index db9e686f..e740e25a 100644
--- a/indi-gphoto/gphoto_ccd.cpp
+++ b/indi-gphoto/gphoto_ccd.cpp
@@ -499,7 +499,19 @@ bool GPhotoCCD::ISNewText(const char * dev, const char * name, char * texts[], c
 
             if (IUUpdateText(&opt->prop.text, texts, names, n) < 0)
                 return false;
-            gphoto_set_widget_text(gphotodrv, opt->widget, texts[0]);
+            char *text = texts[0];
+            char buf[256];
+            if(strcmp("eoszoomposition", name) == 0) {
+                int x = 0, y = 0;
+                LOGF_DEBUG("%s %s", name, text);
+                sscanf(text, "%d,%d", &x, &y);
+                x *= 5;
+                y *= 5;
+                sprintf(buf, "%d,%d", x, y);
+                text = buf;
+                LOGF_DEBUG("%s adjusted %s %s (%d,%d)", name, text, buf, x, y);
+            }
+            gphoto_set_widget_text(gphotodrv, opt->widget, text);
             opt->prop.num.s = IPS_OK;
             IDSetText(&opt->prop.text, nullptr);
             return true;

[anjok]

I don't know if this actually belongs kstars upstream or gphoto downstream, but if we can fix this locally, why not...

[knro]

I think this should be handled at the libgphoto2 level so that it is consistent for all camera models.

[anjok]

until hell freezes over or someone reports it to gphoto, i'm content with this patch I'll leave it here for further reference.

[anjok]

Actually, I think this should be handled here (probably in a bit better way than now, by figuring out the actual size of the PrimaryCCD from the stored settings instead of the hardcoded value "5").

I think this is a misunderstanding on your part of what constitutes the "base" for the scrollers in kstars. It should clearly be the full image size and not the cropped size that you currently use. I don't know if you have other cams that can zoom in, but the name "eoszoomposition" would indicate otherwise. If other cams zoom over the full area, it might be better to fix this in gphoto, but I doubt that's the case....

[anjok]

In fact, you just have to look at the LCD to figure that out. There's a small rect scrolling around in the full view at the bottom right, which should make the scale clear. It's not the video size, but rather the full frame size.

[anjok]

If this were to be fixed in kstars, I guess the range of the scroll widget just shouldn't be based from the preview screen size, but the actual sensor size. Then it would range from 0...4500 instead of 0...900 and also be ok.

[anjok]

But if it were fixed in kstars, the action of selecting a region would need to translate the coords from view -> full size and I'm not sure if that's a Canon-only thing. So again, the best place to fix it is in the driver...

[knro]

How would this patch affects other cameras? Maybe each camera is unique

[anjok]

If you mean other Canon models, on my 450D (which is ASP-C) it works the same as with the 6D (which is full frame). I can't say for others, but if there is a "eoszoom", I would think it's the same. I can't get 10x to work on either though. 5x works fine and as expected. But ARAIR, it was flaky with the old code too.

If you mean other non-Canon cams, I doubt it.

astroberry@astroberry:~/astro/gphoto2-temp-folder/libgphoto2 $ rg eoszoom
examples/preview.c
169:			if (i<10) set_config_value_string (canon, "eoszoom", "5", canoncontext);
172:			set_config_value_string (canon, "eoszoomposition", buf, canoncontext);

camlibs/ptp2/config.c
10572:	{ N_("Canon EOS Zoom"),                 "eoszoom",          0,  PTP_VENDOR_CANON,   PTP_OC_CANON_EOS_Zoom,              _get_Canon_EOS_Zoom,            _put_Canon_EOS_Zoom },
10573:	{ N_("Canon EOS Zoom Position"),        "eoszoomposition",  0,  PTP_VENDOR_CANON,   PTP_OC_CANON_EOS_ZoomPosition,      _get_Canon_EOS_ZoomPosition,    _put_Canon_EOS_ZoomPosition },

camlibs/ptp2/cameras/canon-eos100d.txt
58:/main/actions/eoszoom
62:/main/actions/eoszoomposition
... lots of other canon models which are the same ...

[anjok]

The kstars controls seem pretty weird. you need to set the zoom level and then click in the content area (and probably move?) to get it to update.

[anjok]

Created: #812