"Bad allocation" usually just means you're out of memory. It needs quite a lot of memory, as it's going to hold several copies of the image in memory at once. It probably shouldn't crash PS, but it's not well tested.

16-bit will require 4x as much memory, as it's processing it in 32-bit floating-point. This is to make the math the same as 8-bit, so the results in 16-bit are the same as 8-bit, just higher precision. Handling it as 16-bit directly makes the math come out differently and the results are different, and I don't understand the algorithm enough to understand why, or whether it can be fixed...

Color space handling is patchy; it should work, but it'll often not preview correctly or at all. Filtering a single channel in any color space generally should work, though, since it'll just display it as monochrome.

So I guess there is no way to make the filter reclaim memory from Photoshop (forcing it to write to the scratch disk), just using the scratch disk itself, or maybe (if possible) just grabbing memory from the System pool instead of Photoshop pool?

petopeto said:
If you have something new to say, don't edit posts; just make a new post. Otherwise, it won't show up or highlight as a new post, so nobody will see it.

I edited my post like 30 seconds later. I didn't think it was worth a new post.

So far it's been working quite decently, though I don't understand what each option does.

There is a small manual here:
http://cimg.sourceforge.net/greycstoration/guide.shtml
I'm assuming that "p" is "gfact". The rest pretty much have the same names.

I tried refactoring the threading a bit. On a test image (post #27092, full), set to 60/.7/.3/.6/1.1/1/.8/30/2/1/nearest, it runs in about 13 seconds on my Q9300 (vs. 43.4 with one thread). It still occasionally likes to take 20 seconds instead of 13, though.

Memory usage is about 44 bytes per pixel for 8-bit RGBA. A 3000x3000 image will use about 340 megs; a 6000x6000 image will use about 1.3 gigs. About 56 bytes per pixel for 16-bit RGBA.

Photoshop likes to take over most of the process address space, so trying to allocate memory directly will probably cause problems (in 32-bit, anyway).

Seems similar on my X2 4800+ machine with the above settings on that image. One thread 75.5 seconds. Two threads 38.9 seconds.

With higher quality settings, one thread 1587.2 seconds, two threads 792.7 seconds. Still quite slow but speed does double with two threads instead of one which is welcome.

Any chance of adding something like SSE2 optimizations to speed it up at all or is this as fast as it will get? I can't wait till summer when I plan to upgrade to a Core i7 box.

Also a console window now launches with the plug-in that shows the filtering times. Closing it seems to forcibly exit Photoshop (since it is the Photoshop.exe process). Did you mean to do that?

http://slashdot.org/comments.pl?sid=225270&cid=18245948

Sounds like its doable with a nice gpu for real time filtering....dunno how big MRI images are though heh.

petopeto said:
kiowa, try redownloading; I dumped the VC90 runtime into the ZIP so it doesn't need to be installed separately, but I can't test if it actually works (since it works without that on my system anyway).

Thanks for your attention, but I still get the same error after putting the libraries under PS installiation folder (where there are also some other versions such as msvcr71.dll etc) and system32 folder...How am I supposed to install the libraries?

kiowa said:
How am I supposed to install the libraries?

If putting them in the same directory as the filter or placing them in System32 doesn't work, the proper way is to install the redistributable.
http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2

Cyberbeing said:
If putting them in the same directory as the filter or placing them in System32 doesn't work, the proper way is to install the redistributable.
http://www.microsoft.com/downloads/details.aspx?familyid=A5C84275-3B97-4AB7-A40D-3802B2AF5FC2

Thanks for the link. I installed the package but now I get another error... When starting up PS CS3 I get a popup saying “无法定位程序输入点GetLogicalProcessorInformation于动态链接库KERNEL32.dll上。" which probably means "Cannot locate entry point GetLogicalProcessorInformation on dynamic link library KERNEL32.dll" I suppose.
OK the popup and I'm able to continue starting photoshop, but the filter won't appear. This time I get no SideBySide error in eventlog although.

Does this hotfix help?
Info: http://support.microsoft.com/kb/936235/
DL: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=936235
Edit: It seems what I thought was a download was actually a hotfix request page and it seems you have to access it from the KB page so it includes your language info at the end of the url.

Does the older version of the plug-in work?
http://www.mediafire.com/download.php?djmyymg2jft

What CPU do you have?

If the above doesn't work, it sounds like something may be bit messed up in your Windows installation.

Is your system full patched and updated from Windows Update?

Is there a reason you haven't installed Service Pack 3?

Do you have an install or restore disk which you could do a repair installation of XP?

You may also want to try setting everything in Regional and Language settings to English and rebooting, just to rule that out.

Cyberbeing said:
Does this hotfix help?
Info: http://support.microsoft.com/kb/936235/
DL: http://support.microsoft.com/hotfix/KBHotfix.aspx?kbnum=936235

Thanks for your great solution!! I finally got the plugin working with hotfix 310217. It showed in filters menu correctly and worked in a test run.

I'm using a T7500 dual-core cpu on PM45 chipset, XP sp2 with windows update on.

Updated to GetSystemInfo instead of GetLogicalProcessorInformation, which should work on older systems. (Windows API bug, there: it shouldn't have even compiled, since the program is compiled to be compatible with XP, not just XP SP3.)

Minor speed/memory speedup for 16-bit images. Fixed crash in stage display mode when processing a single channel.

At higher settings, I've always found that greycstoration tends to smear color strangely: color on one side of an edge will appear a distance away on the other side of the edge, with a region of clean color between. The major issue I always have is when I've found the level of blurring I want, but when I set it there, the smears start showing up, too.

Added an experimental alternate amplitude calculation which seems to eliminate this problem. It's disabled by default for now, but if nobody finds any problems with it I'll turn it on by default at some point.

petopeto said:
Added an experimental alternate amplitude calculation which seems to eliminate this problem. It's disabled by default for now, but if nobody finds any problems with it I'll turn it on by default at some point.

If it is disabled by default and doesn't have an option to enable it, how will you know if anybody runs into any problems with it?

What? The option's right there.

Right where? The options look the same to me.
http://img136.imageshack.us/img136/6238/greycswindowcropus3.png

Using the one you currently have linked with a CRC of DF070551 and dated 11/19/2008. I've already tried deleting the plugin cache and it makes no difference.

I don't know, I just re-copied the binary.

Thanks, it seems to be showing up now. CRC D433452D with a date of 11/20/2008.

Generally speaking, I'm happy with plugin. But the "bad allocation" limits its application range...(Any solutions?) Also the algorithm makes splitting image into smaller pieces and then merging into one an undesirable workaround. Also the lack of an auto-profiling and the number of options still make paramenter finding kinda difficult...Well maybe greyc forum is the right place for this topic?

But anyway this GUI already made paramenter finding A LOT easier, that's great. and I think I can bypass bad allocation by finding paramenters in this gui on a smaller area and then copying the paramenters to the commandline greyc? Haven't tried this out though.

I've just never had memory issues; I give Photoshop 1.5 gigs (of my 8). What do you have the memory limit set to, and what size images are you trying to process?

I've noticed that I get a bad allocation if I have done a lot of processing and filtering on the image before I run Greycstoration (I have Photoshop set to 100 History States and 8 Cache Levels). Saving the image, closing and then re-opening it seems to make bad allocation go away.

Also today when I was trying to filter this one image, I kept on getting runtime errors once Greycstoration got half-way through filtering. I tried some other images and they were fine but it seems to hate this one image for some reason. Tried many different settings and 4 different versions of your plugin and the same thing happened with all of them. The Gimp plugin and standalone executable had no issues.
Error:
http://img201.imageshack.us/img201/8530/errorgf8.png
Image that causes the error:
http://moe.imouto.org/post/show/49374/

Has anything changed in the Photoshop CS4 SDK ( http://download.macromedia.com/pub/developer/photoshop/sdk/adobe_photoshop_cs4_sdk_win.zip ) from the CS2 SDK you seem to be using? If so, maybe try compiling it with CS4 SDK and we can see it that fixes it?

petopeto said:
I've just never had memory issues; I give Photoshop 1.5 gigs (of my 8). What do you have the memory limit set to, and what size images are you trying to process?

I have 3GB physical memory and am trying to process a 7000x10000 8bit per channel image under 32bit xp sp2. How to adjust the memory allocation?

You can adjust memory allocation upwards in the "performance" options dialog. You may need to restart for this to fully take effect (not sure).

I'm not sure if 32-bit Photoshop will ever make more than 2gb available to a filter. (The field that exposes how much memory it has is signed...) Currently, a 7kx10k image will need almost 3gb to run, so I'm not sure that'll work anyway--we're coming up to hard 32-bit limits here (swap won't help).

Note that the greyc commandline defaults to tiling; to get the same type of filtering, you need to use -tile 0.

If you're hitting runtime errors, it's probably just out of memory; it wasn't handling OOM in a thread correctly. I've fixed this and I'll update it in a bit, as well as setting the PS hint that tells it how much memory it'll need (which may or may not matter; the documentation doesn't actually say exactly what this does).

I might try an overlapped tile version: work on tiles (horizontal slices, actually; simpler), but yank out much bigger pieces than are actually being processed to avoid tiling artifacts. This would be slower, though, as part of the work for each slice would be repeated twice.

Well, that didn't work (I set it to 17xxMB), thanks for your advice though.
I think I'll use commandline in tiling mode for now.

petopeto said:
If you're hitting runtime errors, it's probably just out of memory; it wasn't handling OOM in a thread correctly. I've fixed this and I'll update it in a bit, as well as setting the PS hint that tells it how much memory it'll need (which may or may not matter; the documentation doesn't actually say exactly what this does).

I think I tracked down the problem. It seems that your Greycstoration plugin doesn't get along with the Adobe's optional "Bigger Tiles" extension. After removing it, I no longer seem to get a Runtime error half-way through filtering that image.

"Bigger Tiles - On computers with > 1 GB RAM, you can optimize Photoshop to take advantage of the RAM in your system and manage memory more efficiently."

Any chance of making it play nice when using "Bigger Tiles"?

Edit: Maybe that wasn't the whole cause. I just got another runtime when trying to apply the filter again after I had already applied it once. It does seem better without "Bigger Tiles" though.

Also, out of curiosity, what are the valid ranges for all the settings.

I've updated with some reworked processing. It now processes images in horizontal slices (currently set to 1000 rows) to reduce memory usage.

It overlaps the processing to prevent the type of artifacts "tiled" mode caused. This also will make it a bit slower (maybe 5-10%). I've been able to process 4000x6000 images in under a gig.

The overlapping is approximate (guessing how much overlap is necessary to avoid artifacts). If anyone notices any artifacts (probably as horizontal lines along the 1000 pixel boundaries), let me know and I'll probably just increase the overlap a bit.

Hey petopeto, I tried using this in PhotoPaint (PS filter compatible), and got an error message:

gFilterRecord->sSPBasic == NULL: -30900

Looks like some sort of assertion / error code. A missing struct from some interface callback perhaps? Any thoughts?

That's the core API for querying other APIs. It's used for all types of plugins. I could probably make it work without it, but then it wouldn't even be able to save settings between runs, and if it's missing that I'm sure other things would be broken, too...

petopeto said:
That's the core API for querying other APIs. It's used for all types of plugins. I could probably make it work without it, but then it wouldn't even be able to save settings between runs, and if it's missing that I'm sure other things would be broken, too...

You're correct, Photo-Paint can't save settings between runs when using other native PS plugins. It's obviously a very partially implemented API they're using.

Still, other plugins I've tried out seem to work fine other than that particular aspect (or at least, I haven't noticed anything wrong in the few I've used). Obviously, it's your call if you want to bother supporting non-Adobe products like mine. Or, if you're interested in opening up the source, I'd be happy to take a look and see if I can fix it myself.