Application Failure : Backyard EOS 3.5.0, x64 RC7 Camera EOS 650D T4i.

[GEB1955]

Ladies and Gentlemen,

I'm using the Backyard EOS software for scanning oversized book pages, generally,

the program works as expected, there is just one problem :

I use a manual radio remote control connected directly to my camera for triggering the shutter, and the program downloads the images to the defined folder, where I pick them up for further editing.

I don't use the periodic shutter trigger of the software, as astronomists might do.

After program start, when I trigger the shutter manually with my radio remote control, the shutter makes its noise, no image goes to the output folder, and the program disappears from my monitor, I suspect an App Crash.

But : when I use the perodic shutter feature ("Start Capture") before I use my manual control the first time, the failure described above, does not happen...

Exactly the same failure happens with the 32 bit version 3.2.3.  

A fix of this bug would be welcome.

The software is really great, it saves me a lot of time, and the quality of the scans is outstanding.

best regards

Gerhard Bauch

Member ; GEB1955

Germany

 

[astroman133]

You are using the program in a way that is unintended by the developers. That is, you are using BYE for camera control, but are controlling the shutter by a different program.

I see similar behavior when I connect BYE to my T5i camera and press the camera's physical shutter to start an exposure. Nothing happens in BYE; no image is downloaded, and BYE disappears from my desktop, and the process is gone from memory. However, if I restart BYE and take a picture with BYE, then subsequent images that are taken via pressing the physical shutter button are downloaded and BYE saves them in the configured folder.

A few things come to mind...

1) It is indeed a bug in BYE. The developers should be able to debug the code to find and fix the bug.

2) BYE uses Canon-supplied software library (SDK) to control all the cameras that BYE supports. However, Canon does not "support" the SDK. That means that they provide the SDK on an "as is" basis and reject any bug reports from developers who use the SDK in their code and do not guarantee to try to fix bugs or add features. In fact there is no mechanism to request feature enhancements or fix bugs. That said, you might try to use the Canon EOS Utility in place of BYE and try to recreate the same issue. Actually, I would suggest that you press the shutter button rather than complicate the test by using your RC shutter control. The reason for this is that Canon does support the EOS Utility and may make investigate the conditions and make some kind of fix, even to the SDK.

3) When you click the Start Capture button, BYE sends several parameters to the camera to ensure that they are in sync with what is displayed on the BYE screen. For example, ISO and f/stop are set. As well, internal message handlers may be set up just before the first exposure is taken. So, if you start BYE and connect it, none of this has happened which might cause the unexpected behavior that you are seeing when you trigger the shutter with your radio remote. If you are handy with programming in C#, you could write a program, or enhance your RC shutter control program to start an exposure, and set the exposure parameters as desired and specify the image download location. The API documentation is installed along with BYE, but is also available on the web site. Also on the web site is an example C# program.

 

[GEB1955]

Hi astroman,

thanks for your response,

some explanations:

I know, that I use the software in a way, that it is not really designed for.

I have this "workaround" by clicking the "Start Capture", before I use my RC device, (which is pure hardware, no software involved, the model ís "Hama Remore Control Ca 1", from the camrea point of view, it works the same way as the shutter button on the camera).  Twio devices, a match box size transmitter, a match box size receiver with a 3,5 mm plug.

Pushing this button produces the same results as the RC does.

The RC is a must, because I'm taking pictures from books, page by page, (thousands of pages during a week) and with touching the camera for every page I would risk to loose the adjustment of the camera.

Using the mouse for every click is no option, because my book scanner and the computer are more than 2 meters away from each other.

Finally, I worked in the software industry for more than 40 years, quality assurance included.

Disappearing programs without an error message are always a "failure" right away. Workaround possible or not.

But as I said, I use this workaround, no big effort....

many regards

Gerd from Germany

[astroman133]

Thanks for the explanation. I am a retired software developer. I have been writing personal and commercial software for 50 years and have been writing C# code for nearly 25 years. As far as O'Telescope is concerned, I am an early adopter of BYE (I bought my license in 2011), a user such as yourself.

I agree about the disappearing programs. However, if some piece of C# code in BYE raises an exception, it should be caught by a last chance exception handler and some cryptic message will be displayed to the user. If the last chance exception handler is replaced in BYE by a null handler, then perhaps this behavior is what the devs intend...I hope not. If the exception is raised on a worker thread, but not correctly marshaled and intercepted by the U/I thread it will be lost. This is something that the devs would need to fix. However, the Canon SDK is unmanaged C/C++ code and a exception here could cause the entire BYE app to disappear if not correctly handled by the SDK and BYE, as we are seeing. So if the error is occurring in the SDK there may be nothing that the O'Telescope devs can do except to try to work around it.

If the only reasons for using the RC shutter control are because of 2 meters of separation and not wanting to touch the camera, you could eliminate the remote shutter and use the USB cable between the camera and the PC along with BYE or the Canon EOS Utility to take and download your picture. You could also write a different app that uses the O'Telescope API to initiate the capture and download the file. This might be nominally faster than using BYE directly and could save significant time given the scope of your project. Both would eliminate the need for the remote shutter.

I assume that your real reason for using a PC-based camera control app is to allow you to see the captured image within a few seconds after it is taken. If I am wrong then you might consider using a regular wired remote shutter with a 3.5 mm extension cable to "stretch" the remote shutter button over to the book scanner, or wherever you need it to be. This would give you a camera-only solution that would save the captured images to the camera's SD card.

Finally, the Canon EOS Utility is a free, anonymous download from the Canon web site. You should be able to test it quickly and if the issue still occurs, contact Canon about their ideas for workarounds or to report the bug. The EOS Utility is free, but Canon does support it. So, if it has the same issue as BYE it would tend to indicate that the SDK is the cause, which may get their attention to investigate.

I hope some of this is useful.

 

[admin]

Interesting workflow you have there.

Are you taking JPG or CR2 images, or both?

 

[GEB1955]

Hi Rick,

thank you for the nice conversation,

seems we worked in similar business environments. The first computer, I learned to write programs for, was an IBM '360 with 8 kB of Main storage and 40 MB of "Hard Disk"...

Most of my professional life I spent on developing database kernels, in IBM Mainframe assembler or Windows or Unix C, but not C++ or C#. I still do some developing for my and my wife's hobby, we're collecting her relatives, another word for this hobby is "genealogy", family history books are the things, we scan and store on disk. The database, we keep our genealogical data is a homegrown product, some kind of a very simple relational database.... 

At the beginning of our scanning project, I really thought about writing a little "remote control" for my good old EOS, but, you know, I have sufficient other software projects, another one seemed to be one too much and the price for the BYE wasn't really extraordinary....

So I tested it and bought it, and it serves my purpose.  I'll definitely stick with it, made a hundred scans with it today, everything's fine.

App crashes, no matter what layer caused the crash, are always anoying for the user, plus they always have negative impact on the reputation of the development team... That's what I wanted to express...

take care my friend

Gerd

 

[GEB1955]

Hi Mr. admin,

I work with JPG only. But the crash happens independent from any camera settings (aperture, shutter, ISO, file format). The destination for the imported JPGs is d:\scanin.

hth

Gerd

[admin]

Is the camera dial set to Manual/Bulb/Tv/Av mode?

Is d:\ a local internal drive or a removable usb drive?

 

Send me the log file. I don't suspect I'll get much out of if because it probably closes before any message gets logged, but having the last successfully logged command may provid a hint.

 

 

 

[GEB1955]

Hi Mr. admin,

camera is set to "M", (leftmost "green" position), aperture and shutter time settings and ISO values are correcty transported to the camera...

d: is a local NVMe (no USB involved), OPsys is Windows 2022 server,  21H2,

Logfile: I found a few...

logfile-[20250226-22h33m09s995]-[15272]-2025-02-26.txt logfile-[20250226-22h41m38s565]-[6832]-2025-02-26.txt

[admin]

Thanks, that second log file does have a valid/good download being requested and downloaded. But then nothing, absolutely no indication and trail to follow

If you take 1 image normally with BYE, that works, right? Does it crash if you then take an image with your remote control?

 

2025-02-26 22:42:56,960 [Main] DEBUG - ObjectEvent_DirItemRequestTransfer: (inRef=2177343349648)
2025-02-26 22:42:56,976 [PropertyGet] DEBUG - IGNORE: PropertyEvent_PropertyChanged Fired! (PropertyId=PropID_AvailableShots), (inParam=0)
2025-02-26 22:42:57,651 [OnDirItemRequestTransfer(2177343349648)] INFO  - Running (log): EDSDK.EdsGetDirectoryItemInfo(inDirItemRef, out dirItemInfo)
2025-02-26 22:42:57,667 [OnDirItemRequestTransfer(2177343349648)] INFO  - Success: EDSDK.EdsGetDirectoryItemInfo(inDirItemRef, out dirItemInfo)
2025-02-26 22:42:57,667 [OnDirItemRequestTransfer(2177343349648)] INFO  - Running (log): EDSDK.EdsCreateFileStream(dirItemInfo.szFileName, EDSDK.EdsFileCreateDisposition.CreateAlways, EDSDK.EdsAccess.ReadWrite, out stream)
2025-02-26 22:42:57,682 [OnDirItemRequestTransfer(2177343349648)] INFO  - Success: EDSDK.EdsCreateFileStream(dirItemInfo.szFileName, EDSDK.EdsFileCreateDisposition.CreateAlways, EDSDK.EdsAccess.ReadWrite, out stream)
2025-02-26 22:42:57,682 [OnDirItemRequestTransfer(2177343349648)] INFO  - Running (log): EDSDK.EdsDownload(imgRef, dirItemInfo.Size, stream)
2025-02-26 22:42:57,871 [OnDirItemRequestTransfer(2177343349648)] INFO  - Success: EDSDK.EdsDownload(imgRef, dirItemInfo.Size, stream)
2025-02-26 22:42:57,871 [OnDirItemRequestTransfer(2177343349648)] INFO  - Running (log): EDSDK.EdsRelease(stream)
2025-02-26 22:42:57,887 [OnDirItemRequestTransfer(2177343349648)] INFO  - Success: EDSDK.EdsRelease(stream)
2025-02-26 22:42:57,887 [OnDirItemRequestTransfer(2177343349648)] INFO  - Running (log): EDSDK.EdsDownloadComplete(imgRef)
2025-02-26 22:42:58,029 [OnDirItemRequestTransfer(2177343349648)] INFO  - Success: EDSDK.EdsDownloadComplete(imgRef)
2025-02-26 22:42:58,029 [OnStateEventHandler] DEBUG - StateEvent_JobStatusChanged Fired! (inParameter=0) (inContext=0)
2025-02-26 22:42:58,029 [OnStateEventHandler] DEBUG - Items transfered!

 

 

 

 

[GEB1955]

Hello admin,

when I take a picture with "Start Capture", before using my RC the first time, then everthing works fine, BYE down loads the images immediately after triggering the RC.

this works stable and reliable.

[astroman133]

As I said previously, I was able to duplicate Gerd's issue with version 3.2.3 and just my T5i camera. Here are the steps:

1) Make sure the camera is in Manual shooting mode.

2) Start BYE, connect to the camera, and put BYE in Imaging mode.

3) Press the physical shutter button on the camera.

No picture is taken and BYE disappears from memory.

This does not happen if I use BYE to capture an image via the Start Capture button between steps 2) and 3).

[GEB1955]

Hi Rick,

confirmed, that's exactly my procedure.

Gerd

[astroman133]

Thanks for the confirmation.

[GEB1955]

you were welcome, Rick,

another little question, I can store Aperture and shutter and ISO, but I didn't find a way to store the Quality. I use "L" with the three steps stairs to the left, in contrast to the "L" with the quater circle...

At the moment, I set this manually per menu on the camera,....

Gerd from sunny Germany

[astroman133]

Per Canon's definition, L with the 3 steps is Large Medium and L with the quarter circle is Large Fine.

In BYE when you shoot JPG images that is Large Fine, by default. It is possible  to shoot Large Medium by selecting that from the camera's Image Quality selector and on the BYE Settings screen choose In-camera for the Quality setting.

I hope this helps.

[GEB1955]

Got it, works fine,

Thank you...

[admin]

15 hours ago, GEB1955 said:

Hello admin,

when I take a picture with "Start Capture", before using my RC the first time, then everthing works fine, BYE down loads the images immediately after triggering the RC.

this works stable and reliable.

Perfect, at least to can make it work by taking an initial bogus picture at the onset.

What is happening is that some variable states (and temp folder states) get initialized only via the capture plan run. By running a bogus plan, these get initialized.

Hope this makes sense.

 

[GEB1955]

For the time being, I can live with the work around.

Medium term, I would like to have this bug fixed.