As RT mentioned, PI requires a bit of everything throughout the workflow. It really depends on what types or projects you like to do. Early image integration tasks tend to benefit from lots of cores and RAM. Post image integration, it varies, but high clock speeds are likely more valuable. For now, only StarXtermintor uses the GPU.
What laptop, CPU, and GPU? A slow GPU might not be any faster than a fast CPU. Also, did you plug it in? Most laptops have a fraction of their performance when not plugged in, especially current Intel systems.
You're just processing a small number of frames, not even as many per filter as the number of threads in the CPU. So the parallel steps are extremely fast. I bet if you do 1000 frames the big time sinks are measurement, alignment, LNorm, and integration. That's just where the arithmetic lives.
Sorry yes I get that but what I meant was your autocrop takes 26 seconds and mine took over two minutes. This is for three files in both cases so for that stage I'd assume the actual time taken would be similar?
Ah I see. Autocrop needs to plate solve each integrated image. Do you have your Gaia XPSD star catalogs stored locally? I put mine (DR3 and DR3/SP) on a fast SSD in the Ryzen server, about 100 GB total. Maybe yours are on the network someplace and PixInsight has to fetch the data through a slow pipe?
I confess I don't know how Autocrop works (I don't see how plate solving would help). It could just try and estimate the cropping boundary on the basis of low SNR at the edges of the (final integrated) image, or it could process each registered sub accurately mapping the "zero" areas left after registation, and accumulating a crop that covers them all. One of these processes one image, the other processes all n images, but is likely to be much more robust. A third alternative would be for StarAlignment to generate a cropping region for each registered image and store it in the image metadata. Each of these options would have quite different processing statistics.
I have a smaller subset of the files, probably 20GB worth so i wonder if that has any bearing on things?
Of course I have no idea how it works but on the assumption it uses all or 3 files then in the latter case mine and airscottdennings autocrop time should be similar which they're not. If it's the former, and given we have "similar" machines then his autocrop should take longer which it doesn't.
Or it just uses the maximum +/- x and y deviations to the reference frame from alignment.
Remember, alignment can rotate and distort each registered frame - it's not just an x, y shift. Also, I don't know if autocrop (a post-integration process) has access to the alignment data. StarAlignment is certainly the best place to determine an accurate crop for each aligned image, but how this can be passed to the later Autocrop process I don't know. Perhaps someone more familiar with the design of the WBPP workflow can tell us.
// ----------------------------------------------------------------------------
/**
* Returns the auto crop region for an image.
* The autocrop region is computed analyzing the low rejection map and the crop region represents the
* the largest rectangle that includes pixels with low rejection values greather than 0.5.
* The method assumes to find the low rejection map store in the image file, if this is not the case
* it attempts to load the file with the postfix "_low_rejection". If none is found then no crop region
* is computed.
*
* @param {*} filePath the file path of the image
* @param {*} keepTheImageOpen if TRUE, the main image window remains open once the function returns
* @returns the Rect defining the crop region of the image, undefined in case of errors.
*/