Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.

Welcome to Stargazers Lounge

Register now to gain access to all of our features. Once registered and logged in, you will be able to contribute to this site by submitting your own content or replying to existing content. You'll be able to customise your profile, receive reputation points as a reward for submitting content, while also communicating with other members via your own private inbox, plus much more! This message will be removed once you have signed in.

  • Announcements

    sgl_imaging_challenge_banner_30_second_exp.jpg

rpineau

Advanced Members
  • Content count

    55
  • Joined

  • Last visited

Community Reputation

17 Good

About rpineau

  • Rank
    Nebula
  • Birthday

Contact Methods

  • Website URL
    http://www.rti-zone.org/astro.php

Profile Information

  • Gender
    Male
  • Location
    USA - CA

Recent Profile Visitors

398 profile views
  1. I've written a bunch of X2 plugin for various devices for TheSkyX. Some people might be interested so I though I'll drop a note here. I usually make them cross platform when possible (which has been the case so far for all of them) so they work on OS X, Windows, Ubuntu and Raspberry Pi : https://rti-zone.org/macosx_x2filterwheel_plugins.php https://rti-zone.org/macosx_x2dome_plugins.php https://rti-zone.org/macosx_x2mount_plugins.php https://rti-zone.org/macosx_x2focuser_plugins.php I hope someone finds these useful. Regards, Rodolphe
  2. I just wanted to let people know that I wrote a focuser X2 plugin for TheSkyX (OS X, Windows, Ubuntu and RPI are supported) for the AAF2. If you're interested you can find it there : https://rti-zone.org/macosx_x2focuser_plugins.php Regards, Rodolphe
  3. Hi Marco. Yea , I forgot about the actual wire protocol. You're right .. 16 bit vs 8 in the usb data packet, even if they do usb bulk transfer async it's still twice as much data so half the speed makes sense. I plan on running more test on the Sun this weekend so I'm capturing at full resolution. I did some ROI test on my dsck and of course the FPS goes a lot higher which will be good for planetary Regards, Rodolphe
  4. Hi Marco. I agree with you about the announced speed... marketing fluff ?... that being said the AD converts 8 or 12 bit. in 12 bit mode it then expands it to 16 bits (left shift by 4 bits and nothing else so this takes no time). so the ratio of 12 to 8 gives almost the 128 FPS they announce for 12 bits... or it is indeed exactly half the speed because the 12 bit AD conversion does take twice as much time independently of the rest of the capture. Not sure either but I've seen the same thing in other apps, not just yours so I'm fairly sure it's not something in the code. It might very well be in their SDK and there is not a lot you can do about this. But I'm already pleased with a 130FPS or 66FPS. Thanks for the great work. Regards, Rodolphe
  5. Hi GuLinux I recompiled the latest v0.7 after updating my QT5 to 5.6.2 and also using the git version of libusb on OS X. Thing seem to have improved and it's also a lot more stable. I can get about 130 FPS in 8bit mode full res on the 174MC and 66 FPS in "16 RAW". So not yet the advertised speed from ZWO (174 FPS in 8 bit mode and 128 FPS in 12 bit (scales on 16 bit)) but that is already a lot better. I also saw that your repo has a v0.8, besides the scripting any significant differences ? Thanks Rodolphe
  6. I don't mean static Qt, just the other lib like libusb, boost and cfitsio... You can still have the Qt lib (or Frameworks on OS X) as Dynamic libs. I wouldn't want the Qt as static either and you can add the dynamic one (the framework) in the OS X app as shown in the link from the Qt doc. Having the other libs as static would allow a use to not have 'brew' or 'mac ports' installed to be able to launch the app. Here is the otool output for my compiled version (otool -L <exec file> gives you the same thing as ldd on linux) : /opt/local/bin/planetary_imager: /opt/local/lib/libopencv_shape.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_stitching.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_superres.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_videostab.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libCCfits.0.dylib (compatibility version 1.0.0, current version 1.0.0) /opt/local/lib/libcfitsio.dylib (compatibility version 5.0.0, current version 5.3.39) /usr/local/QT5/5.6/clang_64/lib/QtOpenGL.framework/Versions/5/QtOpenGL (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1) /opt/local/lib/libopencv_objdetect.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_calib3d.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_features2d.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_flann.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_highgui.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_ml.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_photo.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_video.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_videoio.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_imgcodecs.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_imgproc.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /opt/local/lib/libopencv_core.3.2.dylib (compatibility version 3.2.0, current version 3.2.0) /usr/local/QT5/5.6/clang_64/lib/QtWidgets.framework/Versions/5/QtWidgets (compatibility version 5.6.0, current version 5.6.0) /usr/local/QT5/5.6/clang_64/lib/QtGui.framework/Versions/5/QtGui (compatibility version 5.6.0, current version 5.6.0) /usr/local/QT5/5.6/clang_64/lib/QtCore.framework/Versions/5/QtCore (compatibility version 5.6.0, current version 5.6.0) /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0) As you see I had to chabge the @rpath for the Qt lib to point to my locally installed version (which is not the one from brew or mac ports). I built it with : cmake .. -DCMAKE_PREFIX_PATH=/opt/local/ -DCMAKE_INSTALL_PREFIX=/opt/local -DCMAKE_PREFIX_PATH=/usr/local/QT5/5.6/clang_64/lib/cmake/ -DQt5Widgets_DIR=/usr/local/QT5/5.6/clang_64/lib/cmake/Qt5Widgets/Qt5WidgetsConfig.cmake Then I used the install_name_tool command to change the rpath : sudo install_name_tool -change @rpath/QtOpenGL.framework/Versions/5/QtOpenGL /usr/local/QT5/5.6/clang_64/lib/QtOpenGL.framework/Versions/5/QtOpenGL planetary_imager as I don't have my Qt libs in my LD_LIBRARY_PATH environment variable (DYLD_LIBRARY_PATH on OSX). I'm not asking for these changes, just making suggestion so that OS X user can have a binary that doesn't require a full brew or mac port install with qt5 in it. In any case, I still appreciate your work and effort on this and will do my best to help you on the OS X side of things. Regards, Rodolphe
  7. Yep, cross-compiling for OS X is not the easiest thing :). One thing would be for some low level libs to link in the static lib instead of the dynamic ones (libusb, boost, ...). for the Qt frameworks there is a nice document about it : http://doc.qt.io/qt-5/osx-deployment.html They explain how to add the framework to the app so that the user doesn't need a full Qt install. Regards, Rodolphe
  8. I can try that (compiling is no issue for me). Right now the mac port version I have is 1.0.21_0 So I'll try with the latest git head. I probably won't have time to test before tomorrow. I'm testing on a Macbook Pro Mid-2015 with USB3 port (The ASI 174 MC is USB3), so these issues are probably only software related. Regards, Rodolphe
  9. So I did a quick test and I can connect to the camera and record. The camera can dom up to 128 FPS in 12 bits and 164 in 10 bits. I set the exposure to 1ms, RAW 8bit and I get between 160 and 163.67 FPS, so pretty good (bandwidth set to auto, High speed enabled) If I switch to RAW 16bit (the camera can do 12 bits and expands it to a 16 it value), the FPS fall to about 45 FPS .. I would have expected something close to the 128 FPS the camera can do. Enabling/disabling High speed doesn't do anything in that regards. If I go back to Raw 8bits, i then max out at ~ 75 FPS restarting the app is not giving me back the 160+ FPS in Ram 8bit. I had to disconnect/reconnect the camera, then it was at 120FPS, I then disable the auto mode for Bandwidth, set it to 100% and got the 160+ fps back. I that mode if I switch again to RAW 16bit, it falls to less than 10 FPS. So a few issues but it looks good otherwise Great job. Regards, Rodolphe
  10. Nice ! I was able to recompile it on OS X using mac ports and a local QT5 install I had for something else (so not using the mac ports version of QT5). After fixing a few @rapth to have the the dynamic lib properly loading, I was able to start it I'm not at how so I can test with my ASI 714MC but I should be able to test this tomorrow. Thanks again for the great work. Regards, Rodolphe
  11. No problem. There is no emergency. Thanks again Rodolphe
  12. If you're planning on just using OS X it depends on what astronomy equipment you have. I do all my astronomy on OS X and mostly use TheSkyX Pro to drive all of my equipment (see list in my signature). So the answer depends on your equipment. You might also want to take a look at INDI on OS X : http://www.cloudmakers.eu/xindi/ Regards, Rodolphe
  13. Unfortunately this version no longer works for me (OS X + ZWO ASI174MC). Your previous 1.0.0 beta you sent me was working better. If I chose ZWOASI I get 95 fps but no actual preview no matter what exposure time I chose (so even with 1000 ms it says 95 FPS). If I chose ZWOASI2 I get different amount of FPS with is always above the Max FPS (should not be possible) and garbled data in the preview. Rodolphe
  14. Yes this was on 0.9.0 I use Lynkeos for the stacking and it uses ffmepg to load the file, so whatever ffmpeg supports will work in my case, but probably not for everybody. I'll gladly try your test version. Also using ROI I was able to get a very high FPS with very little dropped frame. So that is a very positive things for planetary imaging. I hope to get the full 128 FPS at full frame size for solar/lunar imaging as this was the main reason for buying this camera (big pixel = bigger FOV on my 102ED = full frame Sun/Moon). I might get an ASI 290MC for pure planetary latter. Thanks Rodolphe
  15. Ok so more data point (with positive outcome ). On the same machine directly on one of the Mac Mini USB3 port, it works but drops a lot of frame (MAX FSP is 125, Actual is 85). On the same machine, on one of the Thunderbolt docking station (Belkin) USB3 port, it doesn't work (MAX FSP is 125, Actual is 0). -> in this mode is does work in AstroLive USB and TheSkyX Pro (and PHD2). On the same machine, on one of the USB3 port of my monitor integrated USB3 HUB, it works but drops a lot of frame (MAX FSP is 125, Actual is 85). On My MacBook Pro Retina, it works (MAX FSP is 100, Actual is 100, few dropped frame from time to time). So it's not all negative (I suspect the Belkin Thunderbolt docking station port are the issue as they are not real full speed USB3 bit only 2.5Gbps max). A few more things common to both machines : If I click on the 16 bit checkbox, FPS drop to the floor ! (MAX FSP is 125, Actual is 22) The camera has 2 modes, 12 and 10 bits, how do I select between the 2 ? Binning 2x2 works but doesn't give me any speed increase. So overall, good result with a few things to look into. I'm mostly concerned about the FPS as the camera is supposed to do 128FPS in full res 12 bit and 164 in 10 bit mode. In both case the CPU cores are nowhere close to be saturated, they went to about 50% on the mac Mini (Core i7 quad core at 2.6GHz) and 35% on the MacBook Pro (Core i7 quad core at 2.8GHz) (using MenuMeters). Which mean the CPU is not the limiting factor for the FPS. Regards, Rodolphe