osx 10.8.2: PI 1.8 RC1 very slow operations

[pfile]

i'm not sure what's going on here, i have never seen anything like this.

1) load calibrated fits file (started life as a CR2 and is still in raw format)
2) open the Debayer process, apply
3) pixinsight is thinking and thinking... progress is crawling in Console window
4) ... wait 2 minutes...
5) debayer finishes

the CPU is 100% pegged during this time. attached is a trace showing all the threads during this time...

[james7]

I've seen the same thing on my Mac OS X 10.6.8 installation of Ripley. Debayer takes forever, several minutes for each image. Under PI v1.7.X it takes all of two seconds for each image. I'm still looking at what may be causing this, I'm going to move everything from my earlier installation out of the Application directory and try another installation.

One other issue (so far), the update for the new documentation fails unless PI 1.8 is at the root of the Application directory. As a first trial I had placed v1.8 in its own directory below Applications but that didn't work when the update tried to run (reported error, can't find necessary files/resources). I then moved v1.8 to the root of the Application directory and the update seemed to work.

Here is an update, it took 425 seconds for PI 1.8 to debayer ONE image. I'm running on a Mac Pro (2x2 2.66GHz Xeon, "Woodcrest" the first processor to support SSSE3) with 10GB DRAM.

Another update, it seems that it is the Debayer process/icon itself that is slow. If I attempt to open a RAW file directly the speed seems reasonable (a few seconds, with the DSLR_RAW format preference set to VNG). However, if you attempt to debayer a file using the process icon it can takes minutes for the debayer to complete. This means that any workflow that requires the debayer process is effectively unusable under Mac OS X.

[pfile]

yeah i should have mentioned that DCRAW seems to work okay.

from the profiler thing i posted it would seem that PI is trying to launch 8 threads (i have 8 CPUs on this machine) to debayer the picture in parallel. there's a whole lot of mutex stuff going on...

in fact, yes if i tell PI to disable parallel processing in the global settings, debayer only takes 10s or so on a 50D CR2. so i think something's jacked up in PI itself or in the way it interacts with the code in Debayer.

[Juan Conejero]

This bug is now fixed by update 20121229-1-module, which we have released today. Thank you for your patience.