>>>>> "Klaus" == Klaus Post <[email protected]> writes: Klaus> Some things were very easy, if there are no spatial dependencies, Klaus> then you just split the image in vertical slices and have each Klaus> thread process each slice, very easy and scales very well.
Obviously. Most photo manipulations can be written as transformation matrices and could in principle be split into a separate thread per pixel. Klaus> The sharpen/denoiser required a job/workqueue to be efficient. Why's that? Isn't that basically just the same thing as above except with a bit of (read-only) overlap? Klaus> The only operation that cannot be multithreaded is image decoding Klaus> (Lossless JPEG decoding to be specific), as it is a strictly Klaus> linear process, where every pixel in the image is depending on Klaus> the previous. Well, if you do manage to parallelise that, I'm sure you'd be in for some kind of award. :-) Klaus> Currently these filters are multithreaded: Klaus> Basic render (color correct), demosaic, denoise/sharpen, lensfun Klaus> (the processing done outside of liblensfun), resample (image Klaus> resize), rotate. What other filters could we expect to be parallelised in future? Klaus> Furthermore the RawSpeed loader is multithreaded when possible Klaus> (DNG images). Why can't they all be multi-threaded? Thanks for the status update. It's quite interesting. Martin _______________________________________________ Rawstudio-dev mailing list [email protected] http://rawstudio.org/cgi-bin/mailman/listinfo/rawstudio-dev
