Skip to content

fix(gphoto2): refactor capture loop to use the event based system#123

Draft
mathisloge wants to merge 4 commits intomainfrom
bugfix/async_capture_flow_gphoto2
Draft

fix(gphoto2): refactor capture loop to use the event based system#123
mathisloge wants to merge 4 commits intomainfrom
bugfix/async_capture_flow_gphoto2

Conversation

@mathisloge
Copy link
Copy Markdown
Owner

@mathisloge mathisloge commented Mar 27, 2026

@fzorbach could you test this branch with your camera?

I've reworked the gphoto2 capture flow to use the event system. The image will now be downloaded whenever a FILE_ADDED event was received.

Unfortunately I don't have a camera with me that speaks the ptp protocol, so i can't test it (and the virtual camera of libgphoto2 doens't support a preview capture).

Maybe one could rework the preview capture using the events as well, but I don't know if any events are emitted for that.

…tead of relying on capture -> download move.
@fzorbach
Copy link
Copy Markdown

fzorbach commented Mar 27, 2026

I didn't run it yet, but from my understanding, you're now waiting on the file added event and using that as the image shown after capture. That hasn't worked for me previously, because the image conversion lib of Qt does not understand ARW (sony raw) files (you're turning the received image buffer into a QImage, which requires conversion). The camera does not assert a file added event for the jpeg (maybe if I configure JPEG+RAW as capture mode). The jpeg is only returned by the capture call.

Using the RAW as the preview is also not a favorable option. The camera applies some color grading to the JPEG to give it the look that was on screen. We don't have that grading for the RAW, so taken images will look different when displayed, probably dull.

@mathisloge
Copy link
Copy Markdown
Owner Author

but with the non event driven approach you will get the raw image? (and just Qt fails to convert the captured image) and after that you just need query the events so the queue is empty?

@mathisloge
Copy link
Copy Markdown
Owner Author

we could add libraw to process the raw files on the go, but this would be a heavier change and wouldn't work around the fact, that a file_added event is not emitted for a raw image. They can perform some optimization.
But maybe it would be better to use JPEG+RAW, show the jpeg and create a logic to download the same image just in the raw format, after the jpeg was found?

gphoto/libgphoto2#966 this seems like a similar case.

@fzorbach
Copy link
Copy Markdown

I think both approaches get the RAW image correctly.

gp_camera_capture(context.camera.get(), GP_CAPTURE_IMAGE, &camera_file_path, context.context.get());

gp_camera_capture wrote the filename of the JPEG for review into camera_file_path, which was then used for display.
The camera does not assert a file added event for this JPEG. Only a file added event for the RAW.

I will try what events I get when I set JPEG+RAW.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants