Problem using best shot selection using Sequator

Started 10 months ago | Discussions thread
OP hha1 Junior Member • Posts: 27
Re: Problem using best shot selection using Sequator

Alen K wrote:

hha1 wrote:

Alen K wrote:

I have not encountered it. For comparison, the largest stack I have done is 260 images. These were 24Mpixel DNG raws. I used "select best pixels" at its default setting (slider midway). I am running 64-bit Win7 with 8GB of RAM. (I should really get at least another 8GB.)

I am running 64 bit Win10 Pro with 16GB of RAM and 7th gen Intel, with the 24 Mpixel images created by the Nikon Z6. The code may not be fully upward compatible with Win10 pro. I tried it with 242 images and default best setting (2 sigma trim) and 2.5 sigma trim, then I tried it with a 99 pictures. All same bad result. Did you notice it takes much longer (factor 6 for me) ?

Yes, using "select best pixels" (which implements kappa-sigma clipping, as I'm sure you know) significantly increases the completion time. But even so, I never considered it particularly slow.

I just did a test. I stacked 20 images with the settings we've been talking about (2.0 sigma). It took 1m04s. Using just accumulation, it took 37s. That's a factor of about 1.7. I next tried 40 images and got 2m52s and 1m16s respectively. That's a factor of nearly 2.3x. Next was 80 images, taking 7m58s and 2m28s respectively for a factor of about 3.2x. Extrapolating, I estimate 160 images would take about 22m and 5m respectively, a factor of about 4.5x. And 320 images should take about 65m and 10m, respectively for a factor of 6.5x.

Bear in mind that I am using just a regular hard-drive, not a solid-state drive. With "select best pixels" a lot of the extra time is no doubt spent writing the temporary files to the hard-drive. That part should be much faster with an SSD. There is also a whack of time near the end "computing and integrating," which would depend on processor speed and the speed of reads from the drive. My processor is an i7-2600 @ 3.4GHz, which I think has four cores.

I would guess that your system should be faster at doing this than mine. If it isn't you might want to contact the author. He does answer emails.

Alen:

Your response "writing to the HD" gave me the clues.

In my original post I had  Sequator reading from the images from a folder on my 32GB SHD card.  In the normal accumulation mode  only the .TIFF output file is written into this folder. In the "best" mode a scratch file names Seqnnnnn.tmp with 193MB is created for each input file.  This will not fit on the SQD card. When I copy the folder with the images on the SSH (it has 251 GB free of  512GB) it all works. The .tmp files are erased when Sequator finishes.

Here are the time with Windows 10 Pro with an i7-7600U at 2.8-2.9GHz. 16GB RAM with a 512GB SSH, with the image folder on the desktop.

For 20 images 0m30s  increasing to 0m42sec with best

For 242 images 2m02s increasing to 14m32s with best.

This tells you the kind of gain to expect from a system upgrade.

Seems like Sequator was not written with the kind of heavy duty work we are putting it to. The software should check if there is enough scratch memory available before starting.

Thanks again for the clue.

hha

Keyboard shortcuts:
FForum PPrevious NNext WNext unread UUpvote SSubscribe RReply QQuote BBookmark MMy threads
Color scheme? Blue / Yellow