Focusing with Bahtinov mask and grabber

Hi guys, fresh user here.
I’m using DSLR with BYE and focusing with mask. I don’t use liveview and instead snap 3 seconds images. The stars with pattern obviously very small, so i use zoom on the brightest star then use Grabber to measure. Now, what is very convenient in BYE, is that when I continue to snap images, they downloaded and showed with exact the same position and zoom, so the mask pattern stays in place and grabber catches it automatically. Then I just adjust the focuser and snap images until I done.
Is it possible in SGP that downloaded images will be also showed with the same position and zoom? So I dont have to zoom manually on each of them and reapply Grabber again?

Thank you,
Sergio

Yes, SGPro will not change the scale of the image between frames.

Hi Ken,
thank you.
I suppose this works only in frame and focus mode?
I noticed when sequence running, all downloaded images are displayed in 100% view mode.
Is it possible to center on specific area in the image with zoom, so the next downloaded images will be presented in the same way? Or am I missing something?

Sergio

No, this works in frame and focus and for normal sequence images (as long as you do not indicate you want a new window for every frame… which is a bad idea anyhow)

This is not true. This is the default behavior, but if it is changed, it will apply to subsequent images (see caveat above).

As a note, I am not sure why you want to use sequence images for bahtinov mask focusing… I am just answering the questions because you asked.

Sorry Ken, I didn’t made my self clear, please disregard focusing with sequence images.

You are right, when sequence images downloaded and got replaced by the new one, the zoom and locations is kept the same. All good.

What happened, is that i had my option “new window for every frame” ON. And downloaded images displayed with “fit screen” (16%) each time, so to compare and check out already taken images I had to zoom to specific section manually on each frame. That felt cumbersome.
Why is it bad idea to have that option on?

Because over the course of an imaging run it can consume an enormous amount of RAM and cause very sluggish behavior of ALL applications on the OS (not just SGPro). That feature is designed to “pluck” a few images off from the rest for reference, comparison or whatever. Keep in mind that if you have 20MB images, they will be in memory twice consuming 40 MB (not to mention the memory that a new window and all its associated windows controls consume). To make viewing of past images easier, we added the “image browser”:

Alright, this is perfectly clear.

Ken, I didn’t want to create new posts flooding the forums, so I’ll ask here.

I noticed that with DSLR (T3i) the string %ct doesn’t read temps reported by the camera’s EXIF, not with Lights, nor with Darks. Already hard job matching DSLR’s darks with lights became impossible, if files got no temp string in them. Is it something broken here on my part or the EXIF temp reading not implemented yet?

Don’t worry about new post topics. We’d prefer you do it so that searches remain relevant.

It seems to be working here with a Canon T1i. Are you saving RAW images, FITS images or both? We use exiftool to extract temperature. What does exiftool report on some of your existing subs?

Also, not related to this issue, but modern processing software (like Pixinsight) does not require darks to match light frame temperature. Furthermore, I don’t even use darks anymore. I just ask Pixinsight to scale my master bias and use it as a dark frame. It works nicely. This is probably camera dependent though.

I tried CR2 and FITS, they both show -500.0C in the file name.

I’m happy owner of the PixInsight :slight_smile: but you are right, we should leave it for another time.

Can you post the results of exiftool run on one of your CR2 files (or post a CR2 to dropbox)?

Here is the link to a file:

OK thanks. I was able to trace the issue down. The problem occurs only if your image file names had white-space characters in them. This has been corrected.

Ken, can you please check the other file too, this had no white space character in the name and got same -500.0C.
I also have uploaded log file here: Dropbox - Error

This is a known bug that we are probably not going to address any time soon (and does not have anything to do with the other bug I fixed). The problem is that cameras for which we cannot determine temperature until the image has been fully downloaded (DSLRs) don’t fit the paradigm (grabbing the temp at the start of the frame as opposed to the end… this is what most folks prefer).

So… as a workaround, Canon cameras will report on temp as follows:

  • First sequence frame will have the camera temp at the time the exposure ends
  • Second and subsequent sequence frames will have the camera temp of the frame before it (essentially camera temp at close to start of integration)

This means that frames one and 2 will always show the same temp… this is not ideal, but it’s better than -500C

Ken, the bug with white spaces that got fixed, is it in 2.4.1.6 or it would be in a next beta?

Thank you.

It is. I forgot to add that to the release notes. This has been corrected.