Note: Beta 2.5.1.10 clicking HFR takes forever now almost 50-60 seconds and almost freezes computer, tried on both machines.
Have to revert to latest stable, more info later.
Takes forever with respect to what older version?
Hi Ken, compared to the last release and any I’ve ever used, I only just jumped on this beta when you mentioned some changes to DCRAW which I was curious about and now finding a massive 60 second delay when clicking the HFR button and waiting for the results.
These are fairly wide field images 480mm / 1.63 scale but I’ve never seen any delay clicking HFR usually it’s 1 second at most.
What camera or how many megapixels is the sensor?
Can you share a FITs or RAW of an image that you’re having issues with?
Thanks,
Jared
Nikon D5300 - 24MP - 6000x4000
Here’s a new sub right now: https://drive.google.com/file/d/0BxRPkA5ux2wlLW1OUU9MWmwzTG8/view?usp=sharing
My i7 computer calculated the HFR much faster about 7 seconds however the laptop and intel compute are dying, hah.
Thanks Ken & Jared.
Hello all,
Just had a go on entilza’s file and it takes around 13 sec’s to put up the HFR circles on my i7 tower.
Tried changing the min star size a few times (13 sec’s in all cases to update result) and I also had SGP
not responding for 30 - 60 sec’s on one change with a white screen before SGP managed to recover from
the situation.
Just thought I’d let you know
Paul
@entilza I’m afraid I cannot really do anything about the speed right now. The new AF method uses very computationally expensive shape detection so that we can support donuts. I highly recommend that you bin your AF exposures… event to 4x4 if required. Image size is the only thing that will decrease analysis time. To this point, subframes, when implemented, will also achieve this same effect.
Ken, thanks for checking. This may be a major issue for me. I don’t use auto focus. I click HFR on the subs as they come in and like to see the HFR number to make sure focus is still good.
Hmm not sure what to do…
I will test the compute stick again but while running last night I don’t think it even came back with stars. Maybe by the time it was done it went to the next sub as I was just testing some short exposures.
Understood.
I need to think on this for a bit, but I’d like to arrive at a solution where subframes can be used for both image history and just clicking the star icon. It is easy enough to do… it’s just thinking about a viable interface and way to implement this that doesn’t add a bunch of extra steps for the majority of users (who don’t need this). I know compute sticks are neat (and very useful for observatories and field computers), but in practice, we may not be able to support them (immediately) for these huge images.
If we can arrive at a solution where image history (it seems like this is what you want instead of manually clicking the HFR icon) uses only a user defined portion of the image, it will make this much faster on sticks and net books.
In the spirit of transparency, any solution that heads this way probably won’t exist in the first release supporting the new AF, BUT we might be able to add a little bit of code, that for images of a certain size, auto (down) scale the image to a more manageable and much faster size.
On a core I5 NUC - and with a 8Mpixel CCD, I didn’t notice anything untoward on the speed front. Focusing curves were good, which included very small donuts at either end of the V.
One question - I sometimes get the V-curve off-center and the AF routine expands out a few points - it gets to the point of drawing another line which looks reasonable but the actual AF point becomes the average of the three red-x’s and not the intersection of the lines. Is this because there are not enough points on the inbound extension to set a confident line fit?
Hmmm I need to test this with my Nikon D810A, if so autofocus will become really really slow, though I use my D810 with refractors I could use the “old” pinpoint method? No?
For clicking the star maybe use the old routine?
I just noticed this to on my imaging laptop and a full res 9 MP that it is slow, but when using autofocus not, as I bin 2x2
/Yves
You probably do not need full resolution for focusing. Even with my 2000mm FL RCT, I bin my AF frames on an 8M camera, so that I am about 1"/pixel. You need to factor in seeing noise and resolution, which for most mortals is 1.5 to 3 "
Your 36Mp camera has 4.8u pixels, my KAF8300 has 5.4u, so maybe the best option is to bin 2x2 or 3x3 and crop down the AF frame by 15% or so.
Ken, Thanks for your time in looking at this.
I’ve spent some more time doing some analysis and here are my thoughts:
Currently (Clicking the “Star” Button on the image preview - which is what I use)
i5 laptop: 10 seconds
Intel compute stick: 33 seconds
i7 desktop: 6 seconds.
Previously this all took 0 seconds on each 3 platforms.
Looking at the CPU usage is strange that it’s not a 99% spike, it’s something like a 15-20% spike during this calculation method. So it may not be using the full potential of the cpu regardless.
I don’t use image history because it added it’s own delay which was different than what the Star button did in between exposures. I noticed this delay on my i5 Laptop as well which is fairly powerful in the past. Not only that when I downloaded NEF and FIT it doubled that delay because it calculates image history on both images. I sometimes take 60 second exposures. Adding 10-20 seconds on each exposure was not acceptable, at the time I stopped using it and have not looked back.
I sometimes use another method for focusing, by actually looking at the HFR values while using the frame/focus routine, I know others who use this method. This delay would be unacceptable here too as I often made many focus changes manually.
I don’t feel this is directly netbook/stick related, as mentioned this was slow on my i5 laptop as well, a minimum 10 seconds added to each sub is not acceptable using image history. Coming from using a tool that was previously instant to a 10-30 second delay is what I am having trouble accepting.
AP has been a difficult journey and I have spent the last 18 months figuring out how to make my system lean and efficient. SGP has been a crucial tool to my AP, and have enjoyed every bit of it. I always recommend SGP to anyone who is interested and hope to continue to do so, especially for new DSLR users who will be using it the way I am using it. Getting it to work as it is now has been rewarding and fun.
The only thing I can perhaps accept is that it does eventually calculate the HFR manually, so if I were to do that at the beginning of a 60 second sub with it would potentially complete before the end of the next exposure. Then I would turn off the Star button so it does not try to calculate it anymore until maybe later I would check up on it… This is my current train of thought on this issue.
I do formally ask that until another solution of a customized frame size for HFR calculations or whatever solution that you offer, can you please leave the old “star” button HFR calculation routine method there as well?
Here is a screenshot of 2.5.0.23 vs 2.5.1.10
Again, just like to thank you for time looking into this and a great product.
More testing - Definitely image size / resolution is the main issue here.
I resized the image to 2300 x 1575 just a basic crop of the central area, and the performance was much better:
i5 laptop: 2 seconds
Compute Stick: 5 seconds
i7 desktop: 1 second
Note compare the two versions of star detections in the previous screenshot. The 2.5.0.23 seems to have a border limiting star detection in the corners. The new routine does not.
Could the “star” button when manually clicked only calculate the HFR for the current crop view of the image preview. This would be very intuitive, this way if full screen it would HFR everything but when cropped to a section just that area. This along with your idea of a custom HFR box for image history may solve everything.
Thanks.
Reading this, I decided to test, what would happen with my i3 laptop 
and my crop dslr frames (5202x3456). Now I image with small censor so have no issues. Downloaded 2.5.1.10 and it took 10 seconds! to calculate HFR, means that if i enable image history, which I very love, that would add 10 seconds delay between the images, which I don’t like at all.
I also noticed that during calculation, only one core utilized and peaked to 80% during those 10 seconds. Is it possible to utilize all cores for calculation?
That’s also my findings with 2.5.1.10?
if image history is on, the whole star calculation is done, adding time to the whole aquisition process.
Would it be possible, as thes frame should be at focus, to use the native star hfr calculation , and not the one used
for AF with dougnuts?
I was thinking that too, but I am not sure how it would work. Both the star icon and image history can be used for purposes of focus so it needs to be sensitive to donuts as well. Adding an option to switch AF methods makes me cringe.
perhaps just switching on/off for history ?
mmmm… too many option…i guess.
I added code this evening to reduce the size of the image (if required) prior to processing. This reduced the find stars time of the image provided by @entilza by about 85%.
Just tinkering with this stuff right now, but the goal is to try and find a universal threshold for reduction. My initial thoughts:
- Width < 3400, do nothing (catering toward the very popular KAF-8300 chip)
- Width < 5000, reduce by 50%
- Anything larger, reduce by 75%
Open to suggestions…
Ken, Thank You for working on this!
Can you clarify the image size reduction? Is this a center crop or resample?
Using the large example from above: 6016x4016 reduced by 75% brings is 1504x1004?