All Activity
This stream auto-updates
- Past hour
-
nikolav_dir joined the community
- Today
-
tyuooo joined the community
- Yesterday
-
thomasverdant joined the community
-
dg1267 joined the community
-
domsto70 joined the community
-
seanchae joined the community
-
imtl joined the community
-
johnsanders joined the community
-
Okay. Thank you, Guylain. Just wanted to make sure my system wasn't the problem.
-
carbonbadu joined the community
-
nightowl joined the community
-
Not in 3.1.7... but I've been working on this for the past 3 weeks... it turned into a major refactoring of the capture plan UI. The next release should have some significant application load time performance to it. Too early to tell how much but there will be a positive difference. Regards,
-
Did these changes make it into 3.1.17? I'm still getting at least a 30 second boot time to the main window on a desktop with Windows 7 Pro with and i7-4770 and 16GB, running from SSD. It is (not surprisingly) slower on my imaging laptop.
- Last week
-
No, Nikon does not support the D3400 for remote control.
-
hay drivers para la camara nikon D3400
-
No chance at all. the 3DX was released in 2008 it is not supported by the Nikon SDK.
-
Any chance for D3X Support?
-
Makes sense. I'm moving this in the feature suggestion box forum. This is where I go for ideas when I have spare time. Regards,
-
Hi, I want to do planetary imaging and my targets have some drift. Right now on my Canon 7D2 I have to use the joystick on the camera body to move the 5x zoom box diagonally across the live view to keep my planet centered. This introduces a lot of camera jitter. It would be awesome if the up/down/left/right keys on the keyboard moved the zoom box while imaging; I'd be able to get a lot more good frames. Using the mouse to move the zoom box requires un-zooming to 1x and rezooming to 5x which also loses time and frames (and confuses stacking software when it is seeing 1x planets and 5x planets in one video)
-
I have a few features on the go now and they are not ready for release. Once this is stable I should have a beta release that should include the 250D. I'm about 4 to 6 weeks away from a beta release ~ this is just an estimate but it seams realistic at my end. Don't worry about the trial limit, I'll grant you a second trial when the time comes... just ask and quote this thread Regards,
-
Thanks for your quick answer, so the problem is caused by the version of BYEOS? Is there any plan, when the next version will be released? I wanted to try out the program in the next 30 days because of the trial limit.
-
You have a newer camera and you got this message because your camera is not currently supported by the Canon SDK available at the time of this software release. It should be supported in the next release. Regards,
-
I just bought the new Canon EOS 250D and wanted to use it with BYEOS. But I had connection problems. When I click on "Connect" nothing happens. The Logboard then says: Attempting to connect camera... Canon drivers 'Canon' initialized. DEVICEINFO DESCRIPTION IS Canon EOS 250D DEVICEINFO NUMBER IS ... YOUR *REAL* MODEL NUMBER IS (Another number) YOUR camera is not currently supported by the Canon SDK available at the time of this software release. I connected the camera via WLAN and Cable but nothing worked. Can you help me with this?
-
OK, I understand about the temp folder. I also do some coding (in Visual Studio) and I understand why you need a guaranteed folder to store data. I also understand making changes to a program can cause unintended consequences in other locations. Kudos for getting the Backgroundworker running on a separate thread (I assume), doing that with a 32 bit application is not easy at all (I've tried, and failed). However, I don't think that saving a file with a long filename should take any longer than saving with a short file name. Most of the filename should be known from the start of the capture (the program already spend 2-3 seconds determining frame rate so there is ample time to work out the file names), camera settings are known prior, it's just the actual start time needs to be added just before capture and that currently doesn't change for the whole capture. Of course it would be nicer if the time incremented in the individual file names during capture, but that takes (a little) more processing to ask the computer for the time. Obviously the counter increases from frame to frame, but this increases anyway. Computers these days are fast, as far as I can see the main bottleneck to the whole process is getting the throughput from the camera above 20 fps Thanks again for your help, this program has made my imaging session much easier and I wouldn't be without it. Andrew
-
The temp folder is a hard requirement and by design. TEMP folder MUST be on a local drive = guaranteed availability DOWNLOAD folder can be anywhere... including and external drive or even a network drive = no guaranteed availability. BYE needs guaranteed folder to store items at run time. It's all about speed in planetary recording. Less code = faster code. The images are dumped/saved with as little of code execution as possible between the image capture and the file dump. This is a fair question though, I guess I would have to run some test and the difference will probably be negligible that it would work too. However, I have learned over the years that changing any code that is working for another version of code is also apparently working may not work in some unforeseen scenarios and this leads to new bugs Regards,
-
Thanks for this, appreciate the quick turnaround on this one. Two questions - why use the temp folder at all, saving directly to the save folder means no extra work on the hard drive ? Second, why not save the file with the long name in the first place? Is there a reason why you just make it a number? Thanks again, Andrew
-
Or better yet, not rename the file and do a straight move. The files would be named "000001.jpg" to "999999.jpg" in the download folder instead of "Planetary_1600iso_1056x704_20190622-14h57m50s_000001.jpg" but that may be just fine because the download folder name where the images are being moved to is already called "Planetary_1600iso_1056x704_20190622-14h57m50s" so renameing the files is more or less a duplicate process, meant only for consistency... but it is by no mean necessary to rename them. I've already fixed this; it will be in the next release.
-
Ok, I looked at code and this is not a straight move, the files are being renamed in the process and a move command does no do rename in the process. so the files are being copied. Perhaps I should rename the file first in the temp folder and then move the files; I'll look into.
-
Is your download folder and temp folder on the same physical drive?
-
Perhaps if the files are being moved from the BackyardTEMP to the Downoad folder while changing their name at the same time this may do a Copy rather than a Move. It may be much less overhead to rename the file in BackyardTEMP and then move it to Download.
-
OK, I understand, thanks for this. It does appear that the files are being copied, not moved, as the File Creation time is different for the raw files kept in the Temp folder to the ones transferred to the download folder. See the images below, I had a few files left over in the temp folder that didn't get removed after being transferred to the download folder. Same "File modified" time, different "File Creation" time. Simply moving them over should keep the same creation time, copying them changes that.
-
It's turned off by default because it there a few side effects using it and these non-intrusive side effect where causing the true beginners / non computer savvy some issues from time to time. One of these side effect is that the background worker process will only use 1 CPU core and therefore takes a bit more time to do tasks that benefits from multi-threading computing but in your case it seems like the side effects bring you a great disk i/o advantage. Another non-intrusive side effect is that the background worker will keep running for a few minutes after you close the app to make sure it is done processing it's task buffer. Regards,
-
I just checked - BackgroundWorker Enabled is not checked by default - I have just checked it on now. I'm taking some dummy data now and watching Task Manager. BYEOS is not using more than about 200 MB while running, and it appears the BackgroundWorker is transferring the files. With the BackgroundWorker on it's taking longer to transfer the files, but it seems to be doing the job well, I've taken 40,000 frames with no problems. Why is the default option to have this off? The user manual does not discuss most (if any) of the options in the Advanced Settings area, could this be enhanced to include a description of what these options do? For instance, what does Processor Affinity mean? It would also be great if the Planetary mode had a histogram feature, so I could check that I was collecting images at the correct brightness. It doesn't need to be enabled during capture, but just to check at the beginning would be nice. It would also be great if you could keep the same date and time for the original temp file (ie 000001.jpg) as for the transferred file (test_Tv115s_200iso_1024x688_20190622-13h00m56s-loop03_000001,jpg). That way I would know for sure what the actual fps was from the date/time for the last frame compared to the first. I would also like to be able to change the file name in planetary mode, you can do it for normal imaging, just not for planetary. Sounds like I'm complaining a lot, but I do think that BYEOS is a great program, and recommend it when I can to other astronomers. If the BackgroundWorker feature fixes my current issues with downloading, that would go a long way to keep me happy :). Thanks, Andrew
-
Hi there, moving the files might be low overhead in terms of cpu and memory, but my hard disk runs at 100% during the download and transfer process and might struggle. I can understand why you use the temp folder for the avi creation, but not for jpg only. The temp folder is on the same partition as the download folder. Why 10,000? From experience, this is what you need for good imaging. People with dedicated planetary cameras use many more. One of my examples is attached. Andrew
-
Moving files to a different folder on the same drive is a very low overhead operation. Only the directory entries are changed; the files are not copied. Are your BackyardTEMP folder and your Download folder on the same drive? Can you watch system memory/BYE memory usage while this is happening? BYE is a 32-bit .NET app and so cannot exceed 2 GB of allocated memory. Just curious...why are you capturing soooo many frames?
