- User Since
- Aug 18 2019, 6:32 AM (27 w, 4 d)
I'm happy to drop this, or to fix it as you suggest. Let me know your preference and if you do recommend the change, which other parameters should be affected as well.
Sun, Feb 16
Jasem, I understand you sentiments, but in this case I respectfully disagree.
Here, the first 3 debug log statements will add at most one line per initiation of autofocus, and most likely nothing at all.
That's 0-10 or 20 lines in logs that can be > 100K lines. The final log statement would add one one line per capture.
While that could be a hundred lines per log, again, a tiny percentage, and could help us debug a hard-to-find bug.
Tue, Feb 11
Restored the conditions for the emit to what existed before https://phabricator.kde.org/D27274
Mon, Feb 10
Mon, Feb 3
Made the filename arg passed to writeImageFile a const.
Made sure the filename was not overwritten when waiting for the thread to complete
Fri, Jan 31
Jan 27 2020
Jan 25 2020
Jan 22 2020
Jan 20 2020
Jan 15 2020
Jan 13 2020
Jan 3 2020
Dec 28 2019
Previous submission had bad user.email, trying again.
Dec 27 2019
Made the background white.
Dec 25 2019
Dec 18 2019
Updates for i18n/i18np and for author header.
Dec 7 2019
Thanks for the review and testing Jasem.
I addressed your tooltip-concern in my latest update.
I don't quite understand how to respond to your other concern (re hiding the contols).
Adjusted stretch button tooltips depending on their state.
Dec 4 2019
The difference is subtle and IMHO it would not be obvious to many users.
I think this is much clearer.
You can try it by disabling the clear--comment out line 184 in fitstab.cpp
Rob, That's working as intended. I clear the button and disabled it when selecting it didn't make sense. It only appears when there's something to do.
I tried it the way you suggest and it was confusing--the user could hit the button and nothing really would happen (e.g. I made an info pop-up, but in the end, I though the better thing to do was this).
Dec 3 2019
Moved from QCheckBox to QPushButton for the stretch and auto buttons.
Auto button is only enabled when it makes sense.
Sorry, the blank auto-button is a little wider when disabled,
couldn't figure out how to avoid that.
Dec 2 2019
Rob: Thanks for describing the bug related to the slider value display. I was able to reproduce and fix. You should not see that behavior anymore.
Fix bug related to updated slider text value when auto is checked.
I implemented Rob's suggestion to disable the sliders and their labels and the auto checkbox when stretching is disabled.
I think this was a good idea.
Disable most of the stretch UI when stretching is disabled.
Rob, thanks for all the suggestions and questions. Let me respond before I make any code changes.
Thanks again for testing and checking out the interface.
Fixed issue when stretching float or double fits file.
Dec 1 2019
BTW, I see the problem with the floating point file.
The issue is that I need to normalize the number--the values needed to stretch are 1/64K as big as the 64K-scale-shorts, and so they underflow the 10000 scale I was using.
I will address this in the next couple days.
Jasem & Rob, thanks for the initial comments.
Fix bug that hid the labels.
Nov 26 2019
This is out-of-date, I guess abandoned, and the new scheme is an improvement, IMHO.
Is there something I need to do to delete/abandon it?
Nov 24 2019
Perhaps I'm missing the obvious, but I don't see it. I don't want to overwrite secondsLabel. How would I use a fall through?
Added secondsLabel update to current change.
Capture should show that it's focusing while waiting for the filterManager.
Wolfgang: Makes sense.
I assume what you mean is that I should do something like this:
just before the call to QTimer::singleShot(), where the text is dependent on filterManagerState.
E.g. if filterManagerState == FILTER_FOCUS then "Focusing...", if FILTER_CHANGE then "Changing Filters...", if FILTER_OFFSET then "Changing Focus Offset...".
I'll modify my change and do that.
That's true, though, as far as I know, that shouldn't happen.
Sorry for not filling that out. Here's what to check.
Nov 23 2019
Nov 19 2019
Fixed file permissions, which were accidentally set wrong.
Removed some of the templating and refactored to simplify code.
Added highlighting to the stretch buttons when the image is stretched.
Needed to run initDisplayImage always in rescale, and not sure why.
Will continue to investigate.
Nov 16 2019
Fixing compile error.
Remove some compiler warnings.
Nov 15 2019
Nov 2 2019
The error is printed in yellow if it is between 1 and 1.5X the accuracy tolerance.
I found in the code that you have a yellow region between 1.0 and 1.5 x the accuracy threshold.
I'll modify it to do that.
Note sure I agree, but would be happy to add a color if you felt strongly about it. It seems like anything at or below the Accuracy spec should be green. I could add a yellow, but in what range would you recommend? Twice the accuracy? Within 1 arc-minute? ...
Oct 31 2019
Wolfgang: Re testing, if you look at the log, WITHOUT this change, even if the stars didn't "flip" after the meridian flip, you should see Ekos sending a "set_lock_position" message to PHD2 at some point after the meridian flip (I'm not sure what happens with the internal guider). If the simulator's stars are in the same position post-flip, then set_lock_position won't hurt it, but the message would still be there. This message is what screwed things up in "real life".
That sounds OK to me.
Oct 30 2019
Actually, I wouldn't be surprised if the thread you're pointing to is really talking about the problem that's being fixed in this PR.
I bet that if that person selected "auto star" his issues would be fixed, and/or if we removed the "if(guiderType == GUIDE_PHD2)" in this change.
Here are the logs:
I replied to to Wolfgang's queston with a Reply-All email, since I was attaching a log and forwarding an email, but I see it went to everyone but Wolfgang.
Sorry about that. I'm now re-sending inside of phabricator and I'll try and make google drive links for the logs:
@wreissenberger: I reported the issue to Rob. The issue comes up only if the "auto star" button is unchecked in the Guide tab. For me, 4 or 5 nights in a row last week I failed to guide after a meridian flip until I looked into the code and logs and discovered the root cause.
You said: --Also right now with the current behavior with Ekos and PHD2, if the user has auto-star unchecked but has not clicked on a star to force PHD2 to use that star for guiding, then it lets PHD2 select a star automatically and doesn't force it to use a different lock position. It is only if the user has auto-star unchecked and then the user selects a star to use for guiding in the guide image that it actually makes PHD2 use that star when guiding. So really you don't have to have auto star checked as long as you don't select a guide star it will still guide automatically.
Oct 29 2019
Robert, Thanks. These changes do see to address my issue, and I believe would be an important improvement. However I have a couple questions/suggestions:
Oct 27 2019
I tested this with my ASI1600, where the .fits files are 32.8Mb. Works fine.
In fact, it's likely that the larger the file, the more the speedup--as I guess the disk-write would take longer.
The only place where there would be extra memory used is where I do the memcpy in indiccd.cpp:1470.
I wasn't sure I needed to do that, but I didn't think I could rely on the blob memory staying put, so I conservatively
ran the memcpy, and created that buffer that I keep around. That memcpy takes less than 100ms on my RPi4 with Release build.
Oct 13 2019
Oct 8 2019
small changes: tr --> i18n and slotChanged --> valueChanged
Added a don't-set-gain value.
Oct 5 2019
Oct 2 2019
Oct 1 2019
Sep 27 2019
OK, I'll take a look at it and come back to you with a proposal or code-review.
I agree it's not a perfect UI. I do think it is nice have the ability to see the unstretched image.
Sep 18 2019
When I look at the image you sent me, either in Pixinsight or Fitsviewer, it seems like it's a 1-channel image (I assume it's not debayered--it has seems to look like a bayer pattern).
That is, it doesn't seem to display as a color image before or after my change.
Does it work differently for you?
Please send instructions on how to test this image, or please send me an image that would display with color (or show 3 medians for R, G & B) on the original software.
- Updating D24041: # Enter a commit message. # # Changes: # # kstars/fitsviewer/fitshistogram.cpp #
- Enter a brief description of the changes included in this update.
- The first line is used as subject, next lines as comment. #
- If you intended to create a new revision, use:
- $ arc diff --create