SharpCap Forums

Hi Robin,

I’ve noticed an issue when using Focus Assistant (or Seeing Monitor): setting Black Threshold too high not only leaves the ROI greyed out, but also affects the frames delivered to the BeforeFrameDisplay and BeforeFrameWritten callback handlers. In this state, the callbacks receive altered frames (see attached screenshot) rather than the expected calibrated data.

Request: it would be very helpful if at least one callback always received the unaltered calibrated frame (bias/flat applied) and remained unaffected by tools like Focus Assistant and Seeing Monitor.

Thanks for considering this.
Regards,
Leo

Hi Leo,

it's expected that the modified image arrives at BeforeFrameDisplay - that's how the image with the shaded out dark areas appears on screen. However, the BeforeFrameWritten event should receive an unmodified copy of the image (if it didn't then the saved image would contain the shading, and that shouldn't happen either).

If you are seeing the modified image in BeforeFrameWritten then there must be some sort of bug, but it doesn't seem to happen in my testing here, so it may be specific to certain camera configurations or be triggered by something else. If you capture an image/video with the shading active, please check to see if the saved images are affected. The best thing then would be to send me the capturesettings.txt file from that image/video - that will give me enough info to set up my test as similarly as possible to yours.

PS. There is also the 'FrameCaptured' event, which happens when the frame comes off the camera before any processing or analysis - not sure if that is useful to you.

cheers,

Robin

Hi Robin,

Apologies, my test notes were incorrect. I thought I had used BeforeFrameWritten in one case, but I actually used BeforeFrameDisplay in both. For my use case I can’t rely on BeforeFrameWritten during live preview, and neither BeforeFrameDisplay nor FrameCaptured is ideal. A callback that always received the calibrated frame (bias/flat applied) without the shaded overlay would be perfect.

Regards,
Leo

Hi Leo,

if I added a 'BeforeProcessing' event, it would end up being almost identical to 'FrameCaptured' in timing and information available to you. The only possible difference is the 'BeforeProcessing' event might fire less often if the processing is slow enough that some frames from the camera are not processed because the previous one is still being handled.

So, I guess the question is... Why doesn't FrameCaptured fit your situation, since it might be best to see if that can be addressed.

cheers,

Robin

Hi Robin,

Thanks for considering my request.

Why FrameCaptured doesn't fit my use case: it only fires during capture. I need a steady trickle of frames during preview as well, so my application can analyze images before, after, and during captures.

I specifically need the calibrated image (bias/flat applied) before any UI overlays (Focus Assistant shaded ROI, selection boxes, etc.). Raw frames carry dust spots/artifacts that degrade image processing accuracy, and BeforeFrameDisplay can be altered by overlays.

If a BeforeProcessing event could:

• Fire for both preview and capture frames,

• Deliver the calibrated, unaltered frame (no shaded areas/overlays), then that would be perfect.

Regards,
Leo

Hi Leo,

ah, OK, well the first issue isn't an issue, just that the name of the 'FrameCaptured' event is misleading you. That one is fired regardless of the capture status in SharpCap, the name is really referring to the frame being captured from the camera. So, that event should be OK for you except that it occurs before dark/flat processing.

But, that event does occur before dark/flat correction, and there is no way for you to force the running of the dark/flat at that point as the information on what to do hasn't been attached to the frame yet when the event fires (anyway, running the dark/flat correction at that point could have unintended side effects).

So, I think we have exhausted the possibility of using existing events - I will have to look at creating a new one...

cheers,

Robin

Hi Robin,

You’re right, and again, my apologies - I mixed up the names of the two handlers. I meant BeforeFrameWritten, not FrameCaptured. But you got my main points right.

Thanks,
Leo