search

CarVac / filmulator-gui

Filmulator --- Simplified raw editing with the power of film
https://filmulator.org
Other
669 stars 31 forks source link

Req: Defer processing full-size image until after user chooses to save image #117

Closed xiota closed 3 years ago

xiota commented 3 years ago

I'm working in a slow computer. It would be nice if the program didn't process the full resolution image until I'm done trying different settings to see their effect.

CarVac commented 3 years ago

Is this an issue of battery power or of responsiveness?

Is the full resolution processing not interrupted as quickly as you'd like?

This is probably doable but the way I've coded the save buttons, the entire UI locks up while it writes the image to prevent messing with the settings and so I'd need to do a bunch of rework there.

xiota commented 3 years ago

It's a responsiveness/performance issue. I'm using the AppImage of version 0.9.0. This is my first time trying filmulator-gui.

When I change a setting, I see that a progress bar shows completion of a task, the preview image updates, then the progress bar restarts and takes much longer. During this time, the sliders appear to be unresponsive. If I try to click and move them, the mouse becomes jittery, even freezing momentarily, and the task seems to take even longer to finish. From my perspective, it did not appear that processing could be interrupted at all.

My computer is slow. It works okay for JPGs in GIMP, but with RAW files, I can only work at reduced resolution or with partial previews. It would actually be my preference to save settings to a sidecar file that can be used with a separate command-line utility to batch convert files. That is how I use other programs like Hugin and RawTherapee.

CarVac commented 3 years ago

Hmm, that's not expected behavior, even on a slow computer.

At any time while processing, the sliders should be free to move and will interrupt the full-size (or indeed even the preview-size) processing at each update of the progress bar, sending it back to recompute the preview size.

If you have a hard disk, clicking and releasing the mouse button triggers a write to the database and that can cause a momentary UI hiccup, but that shouldn't take that long to finish up. If you instead click and hold a slider, it will delay the database write until you release the mouse button.

What are your computer specs?

xiota commented 3 years ago

Normally, I try to get settings right in camera because this computer isn't suitable for heavy editing.

Also, Plasma became slow to respond/unresponsive, so it was difficult to switch to Firefox to just click around the internet while processing finished in the background. I tried closing programs like Firefox, GIMP, geeqie. Only other programs open were file manager and terminal. Didn't seem to make any significant difference. I was working on files on a ram drive (/tmp is using tmpfs). I did not check swap partition usage.

xiota commented 3 years ago

I just tried again... it's been a few reboots since I last tried, so there might have been something I wasn't aware of that was eating up processor cycles earlier...

My feature request still stands though. Changing settings occurs much more often than file save, and the intermediate steps are ultimately thrown away. So it's very inefficient. Other raw processors appear to reprocess files from scratch when exporting to tif/jpg, and the preview is just a preview. So it seems reasonable to defer full processing until file save or batch processing, etc.

CarVac commented 3 years ago

Perhaps the better route would be to check for interrupts more frequently.

What resolution are the raw files you are processing, and how long does it take to perform processing? (copying the terminal output of the program from processing one photo will show me some durations so I can get an idea)

xiota commented 3 years ago

It's already slow and inefficient. Checking interrupts more frequently is just going to eat up more processing cycles, making it even slower. How about...

Add an option to defer processing full resolution images. People who like it how it is can leave it off. When the option is enabled, add a button to "Process Full Resolution". The "Save TIFF/JPEG" buttons can be disabled until after the "Process Full Resolution" button is pressed.

The image is 24mp (6032x4028). When I click to drag the Highlight Recovery slider, it shows:

FilmImageProvider::requestImage Here?
FilmImageProvider::requestImage id: q000014
imagePipeline.cpp: Opening /tmp/20200115-145156.28187.raf
load start:0.000223
raw width:  6032
raw height: 4028

I let go of the slider... wait a second... click to drag again... wait another second... then click to drag again. Then wait... The following starts showing up:

demosaic start0.06793
demosaic end: 8.54828
load time: 23.81
ImagePipeline::processImage: Demosaic complete.
scale start:23.8103
scale end: 18.3149
hlrecovery start:42.1995
lensfun start
FilmImageProvider::requestImage Here?
FilmImageProvider::requestImage id: q000017
imagePipeline.cpp: Opening /tmp/20200115-145156.28187.raf
load start:5e-05
raw width:  6032
raw height: 4028
demosaic start0.004376
demosaic end: 6.89532
load time: 7.09661
ImagePipeline::processImage: Demosaic complete.
scale start:7.09683
scale end: 1.32291
hlrecovery start:8.41984
lensfun start
rmult: 1
gmult: 0.999991
bmult: 1
rCamMul: 2.06954
gCamMul: 1
bCamMul: 2.03642
ImagePipeline::processImage: Prefilmulation complete.
ImagePipeline::processImage: Filmulation complete.
crop start:11.3645
crop end: 0.015284
qml: top image ready
qml: TopImage state: lq
FilmImageProvider::requestImage Here?
FilmImageProvider::requestImage id: f000018
FilmImageProvider::requestImage filename: /tmp/20200115-145156.28187.raf
imagePipeline.cpp: aborted at demosaic

I don't know if this is significant, but the above abort message showed up about a minute after I had dragged the slider earlier. I don't see any other abort messages even though I had changed the setting three times. More waiting...

qrc:/qml/qml/filmulator-gui/Edit.qml:117:17: QML Image: Failed to get image from provider: image://filmy/f000018
qml: top image errored
FilmImageProvider::requestImage Here?
FilmImageProvider::requestImage id: q000019
qml: top image ready
qml: TopImage state: lq
FilmImageProvider::requestImage Here?
FilmImageProvider::requestImage id: f000020
FilmImageProvider::requestImage filename: /tmp/20200115-145156.28187.raf
imagePipeline.cpp: Opening /tmp/20200115-145156.28187.raf
load start:0.000159
camToRGB: 
camToRGB: 
camToRGB: 
load time: 12.399
ImagePipeline::processImage: Demosaic complete.
hlrecovery start:12.3993
lensfun start
rmult: 1
gmult: 0.999991
bmult: 1
rCamMul: 2.06954
gCamMul: 1
bCamMul: 2.03642
ImagePipeline::processImage: Prefilmulation complete.
ImagePipeline::processImage: Filmulation complete.
crop start:67.0507
crop end: 0.205085
qml: top image ready
qml: TopImage state: lf
qml: main.qml queueItem update url
Thumbnail being written to: /home/xiota/.local/share/filmulator/thumbs/a354/a3541463202c7001c901965128454ac40001

About 3 minutes have elapsed since first dragging the slider. During this time, the entire system was glitchy. Even trying to type in a text editor was unpleasant.

CarVac commented 3 years ago

Quite frankly, I think that because Filmulator is intensely computationally expensive, I don't think it will ever be useful in interactive editing on a machine as slow as yours, and I'd rather not complicate the editor view code any further by having it defer requesting the full size image. Even if you do defer it, the GUI is not set up for batch output, so it'll take another 60 seconds before you can even start working on the next image after saving.

As you asked in your previous issue, it would be quite feasible to split out the current optimized code into a simple batch-processing program and edit the output with RawTherapee or another editor, as I used to do before writing the GUI.