Close
The source is linked earlier (somewhere), but it's out of date and I'll hopefully have a new release in a day or two. I'll just have it tolerate that error and see what happens, but this is one program you're really going to want to save settings with...
Hmm, must have missed it. I'll take a look (sort of curious anyhow).

Yeah, I hear what you're saying about the settings, given the tweakability / complexity of that filter. I might just see if PhotoPaint has a native API I can use to write my own plugin, since they obviously don't fully support the PS API.

I'll have to think about whether I want to invest such a large amount of work in this project, though. You know how that goes, I'm sure. ;-) I have to say, I'm pretty impressed with the stuff you've done with this site, as well as the extras like this plug-in.

Anyhow, thanks!
petopeto said:
(just making it available since it's probably useful to a lot of people here).
Just tried it out - certainly useful! Thanks!
This is a major update, including a lot of performance improvements and a general UI update.

http://moe.imouto.org/GreycShop.zip
source: http://moe.imouto.org/GreycShop-src.zip

Short list:

Added OpenGL acceleration and SSE optimizations.
Pre-blurring (roughly the same as doing a gaussian blur before greyc)
UI improvements
Thread count selection.
Reset defaults (alt-cancel)
Copy settings to clipboard (to paste on forums)
Quick save (alt-OK)
Zoom is now alt-mousewheel
Actions cleanup
Alt. amplitude on by default
Added side-by-side and in/out view modes

Big scary details in a separate post.
Added OpenGL acceleration.
This is disabled by default, so if it crashes for some people, it won't make the plugin unusable. Turn it on.

It works on my Geforce 9600, and I've also tested on a 6600. Untested on ATI. Runs about 3x faster than in software on my Q9300 (quad-core).

This only supports up to 4 channels: RGB and CMYK should always work, but if you filter a layered CMYK channel, the alpha channel won't be filtered.

Runge-kutta interpolation isn't supported in OpenGL (but I've never noticed a difference anyway). Linear is suppoted and much faster, but that doesn't seem to make much of a difference to me, either.

Added SSE optimizations
If you're not using OpenGL, you won't notice much of this, because the stuff that's been optimized is only stuff that's not OpenGL-accelerated.

Thread count selection
Selects the number of threads used. The default of "auto" will use one thread for each CPU/core, as usual. Auto-1 will use one less, which can improve responsiveness if you're doing other things while greyc runs. (Lowering scheduling priority doesn't seem to help here, for some reason...)

Pre-blurring
This is the same as simply running a gaussian blur before running the filter. This is often an initial step in filtering, so this is included to allow tweaking and comparing this step along with everything else. The default of 0 causes no pre-blurring. The blurring tries to be the same as Photoshop's Gaussian blur.

Reset defaults: Hold ALT and hit "Reset" to load defaults.

Copy to clipboard
The "Copy" button copies the current settings to the clipboard, in a form more or less like the greyc commandline. (Settings that don't exist in that version are given fake names.) This can probably be used to paste to other versions, but this is mostly intended for pasting on forums: it's quicker than typing it all by hand, and it gives everyone a standard format to list settings.

Quick save
Hold ALT and hit OK (or press alt-enter), and the it'll exit and save settings as if you had hit OK, but not actually process the image. This is useful to modify a recorded action, or to just save where you are, without having to wait for the filter to finish and then undo it. It's also handy when I've set up a filter, but then remember that I wanted to duplicate the layer first...

After this, you can also run the settings you just saved with Last Filter (top item in the Filter menu, or ^F).

Actions cleanup
Most people don't change da, dl, etc. They're no longer shown in the action now if they're not changed, so the action view is cleaner.

Split out some settings. The stuff in the "Advanced" box is stuff most people won't need to change.

Zoom is now alt-mousewheel. Changed this to line up with Photoshop's interface.

Turned alt. amplitude on by default. I've yet to see any problems with it, so I turned it on and stuffed it in Advanced.

Adjusted setting names to line up with the command line and GIMP. The commandline names are shown on screen, too (including some fake ones, for reference with Copy).

Maybe increased compatibility with hosts that don't provide gFilterRecord->sSPBasic.
Cool..i'll give it a shot sometime today.
Cool, much better
Updated to fix memory usage (r37). Also, removed the revision from the link so the link doesn't keep changing.
petopeto said:
Updated to fix memory usage (r37). Also, removed the revision from the link so the link doesn't keep changing.
I tried r37 on a 7000 x 10000 8bit/channel RGB image and it crashed my photoshop...(A dialog prompting you to send error report appears)

This doesn't seem to happen on smaller images, and also I don't know if r36 has the same issue since I have deleted that already.
petopeto said:
Maybe increased compatibility with hosts that don't provide gFilterRecord->sSPBasic.
Heh, thanks for the effort, but it crashed without reporting any error this time. I wouldn't concern yourself with it. It's tough enough just dealing with Photoshop-related issues from the look of it. ;-)
The with GPU (OpenGL) enabled, Greycstoration (r36 & r37) seems 1000x+ slower then without. I even tried doing a clean install of Windows XP Pro SP3 x86 and there was no change. Both Photoshop CS3 and CS4 have the same problem also. My graphics card is a 7800GTX 512MB using Forceware driver 178.46.

After monitoring my GPU in RivaTuner, it seems it is not even touching the GPU. No GPU memory usage, and the monitor doesn't show OpenGL acceleration turning on. This suggests that Greycstoration is trying to do the OpenGL operations emulated in software, and is supported by the fact that nvoglnt.dll is maxing out one core of my CPU, which is not normal.

Any ideas petopeto?
I've tested in XP64 (crusty install) on a GeForce 9600GT 256MB (180.48), and on an old machine with a new XP install and a GeForce 6600GT. (Both in CS3, but I doubt the version will make any difference.)

I've updated (r39) with a few changes, including a check for software rendering (it'll just throw up an error).

If it doesn't work, hold down left-control-shift when you select the plugin, and it'll open the diagnostics console window when the plugin starts. (Don't try to close that window--it'll crash Photoshop.) Check that the vendor and renderer outputs look correct; they should be "nVidia Corporation" and your video card.

Also reduced memory usage a bit more; 10000x8000 done in about 1.1 gigs. (It'll always be more than the commandline, since Photoshop always wants to keep extra copies for undo, history, etc., but it should be low enough now to not matter. If you're trying to edit images that size, you really need more than a gig of RAM...)
Great job, now at least I get a low RAM error dialog from photoshop itself rather than an upsetting crash report from windows. (I maxed out the memory usage to 1701MB)

This isn't a big problem anyway since I don't deal with such large images often, and I can always manually tile them.

Also, I opened the diag window and the gpu was working, but I have not tested speed yet.
But wait---gpu rendering is giving me strange artifacts on high iteration counts (such as 5)?

the source is #54347
http://i.namipan.com/files/8a0f78ab35fc10412b4b608b1393f5d8ba2c3bf278f902007552/0/greenshot_2009-01-11_10-19-40.png
http://i.namipan.com/files/cc1242c6467305e1a90a7911b49a6f02979f236c41ea0200ab29/0/greenshot_2009-01-11_10-19-43.png

the links are two screenshots, between which only GPU checkbox is changed and the GPU version has strange black dots on it.
(Maybe you won't need it at all since this phenomenon is not difficult to find)
Any ideas?
I opened a small 1024x724 jpg, started Greycstoration, and it took about 27 minutes (3350x longer then CPU >_<;;) just to generate the preview window using the GPU and it produced broken output.
GPU preview result: http://img70.imageshack.us/img70/4773/gpufilteredkb2.png
OpenGL error 1285 = out of memory.

It took 0.5 seconds using CPU with correct output.
CPU preview result: http://img74.imageshack.us/img74/8528/cpufilteredge0.png

I'll try updating my driver to the new 181.20 WHQL and see if it makes any difference.
________________________
Settings = Defaults (GPU)

Threads: 2
Block queued: 0x0
Timing (prep): alpha blur 0.011000
Timing (prep): geom_factor 0.002000
Timing (prep): get_structure_tensorXY 0.022000
Timing (prep): sigma 0.013000
Timing: prep 0.053000
OpenGL vendor: NVIDIA Corporation
Renderer: Geforce 7800 GTX /PCI/SSE2/3DNOW!
Timing (GPU): init 0.081000
Timing (GPU): texture load 0.007000
Timing (GPU): G2 1.002000
Timing (GPU): prep 0.289000
Timing (GPU): main 1623.994000
Timing (GPU): finalize 0.008000
OpenGL error 1285
Timing (GPU): finish 2.005000
Timing: GPU total 1627.409000
Timing: took 1627.506867

__________________________________

Settings = Defaults (CPU)

Threads: 2
Timing (prep): alpha blur 0.011000
Timing (prep): geom_factor 0.002000
Timing (prep): get_structure_tensorXY 0.021000
Timing (prep): sigma 0.013000
Timing: prep 0.050000
Timing: do_blur_anisotrophic 0.041000
Timing: do_blur_anisotrophic 0.041000
Timing: main 0.327000
Timing: main 0.327000
Timing: took 0.485930
In my case GPU rendering is much faster... but it also generated broken results (not as severe as yours though).
Well I tried it with 181.20 and the result was the same. It just doesn't like my GPU for some reason.
Updated (r45) to fix a glitch that was causing all images to be processed in 32-bit (only 16-bit images should be handled that way), which made GPU processing slow probably on anything older than a Geforce 9. (Can't test everything on the older hardware, since it's downstairs and stupid remote desktop doesn't like OpenGL...) Also, fixed a math issue (grr, atan2 in a pixel shader isn't the same as atan2 in C) that was causing artifacts when alt. amplitude was turned off.
r45/ PS CS3/nv 9300M GS

Just tried it out, found the artifacts gone, great.
Also, even on a weak card such as nv 9300M GS, GPU mode is still a few times faster(6.63s vs 43.55s in my test scenario)

Also, GPU and CPU rendering produced identical results, except only a few pixels different by 1 level.

But for just once I had a strangely blurred preview window as cyberbeing had in the screenshot, it returned normal after panning the view a little, and I was not able to reproduce that error. It could be a giltch, but it may also be just my mistake...
Updated to fix a significant memory leak; also cleaned up the preview window for smaller images.
I just tried it again with the latest version and it is now working properly with my 7800GTX 512.

When I processed a 6072x4300 600dpi image with default settings:
CPU took 174 seconds
GPU took 26 seconds

It also seems work fine even when I have all OpenGL acceleration features enabled in Photoshop CS4, which is nice.

Thanks petopeto.

Would it be possible to add the revision number to the preview window title?

Could you also add the zoom percentage to the the preview window? It is hard to know when you are back to 100%. Zooming out has always seemed to produce an ugly preview. Any chance of improving the preview downscale resizing (using bilinear)?
Well I noticed an issue. If I use Gfact of 5 or above with GPU acceleration, I get black artifacts in areas of high contrast. Gfact of 4 and below seem fine.

http://img174.imageshack.us/img174/1074/artifactskm5.png
http://img115.imageshack.us/img115/5789/artifacts2jv8.png
It's pushing the numbers out of range, and the GPU starts treating them as infinity, with not very useful results. I've never found gfact useful, anyway; it scales the input, so if you have a very dark image, you can "brighten" the image for the structure determination, but I don't think you'd need anything higher than 1.5 or so for that.
petopeto said:
It's pushing the numbers out of range...
How do I know if numbers are in range? Is Gfact of 5 and above the only thing that will produce out-of-range numbers? Is it out-of-range for GPU only?

I remember asking you before what the valid ranges for all the values were, but you never gave me an answer. Do you know? As a test, when entering 100000 for all the values, it seems to silently exit/crash, so there must be a valid limit for each value, right?

In the older CPU-only revision, I remember sometimes seeing it produce scattered semi-transparent pixels in dark areas. Could that be caused by out-of-range values or do you think it was caused by something different?

As for Gfact, normally I have found values up to 3 sometimes useful. That image just had a lot of low frequency noise, so I was using a high alpha value and an unusually high Gfact to detect all the structure (brightness wasn't an issue).
The only strict bounds are a few that have to be positive (eg. dl, da), most can't be negative (negative gfact causes normalization instead of scaling), and anisotropy (-p) is clamped to <= 1 (a percentage).

I havn't crashed it with any settings. It throws out of memory with some (very high values of pre-blur make it try to allocate a large buffer region).

Large -dt values in GPU mode will be clamped--it'll only sample to a distance of 32 pixels as a sanity check (if the driver thinks a fragment is infinitely looping, it'll cancel it), so if you set -dt 100000, it won't actually sample as much as it does in CPU mode. (Note that -dt is logarithmic, and the distance actually sampled depends on the image, and also on -prec.) I can increase the limit if someone actually finds a case where it matters.

GPU processing for 8-bit images is done in 16-bit; CPUs don't support 16-bit floats, so it runs in 32-bit. A very low value of da can go out of range: it does 360/da passes, adding each together, so a very small da value can lead to a very large result (this could be fixed, but I don't think it's useful anyway). In theory, a high sample length (eg. da = 0.0001) could, but the sampling will be clamped before that happens.

If you convert the image to 16-bit, it'll use 32-bit floats, which may not do this, but that's probably slow on anything older than a Gef9.

I've never really seen gfact do anything but reduce smoothing...
By the way, where can I find a full documentation about these paramenters? greyc official site has only some of them.
kiowa said:
By the way, where can I find a full documentation about these paramenters? greyc official site has only some of them.
i was gonna ask the something similar.
is there a User's Manual for this plugin? i'm trying random, high numbers on each parameter, i click "preview", the bar loads and nothing happens, i can't see the image quality improves.
i'm completely lost here.
any example what this plugin can do, or what it is supposed to do?
something like this? http://cimg.sourceforge.net/greycstoration/guide.shtml
Unfortunately there isn't really much documentation beyond what you see there. If you do a google search you may be able to find a couple more examples.

Here is a brief rundown of the general effects I've seen from each function. Maybe petopeto could fill in some missing technical details.

Strength = a.k.a. Amplitude, high values for more blurring (Use Normal view for tweaking)

Contour = high values for a sharper image (Use Normal view for tweaking)

Anisotropy = high values for a sharper image, different and less intense then Contour (Use Normal view for tweaking)

Noise Scale = Since it's called alpha, I assume it is for determining the alpha threshold to be considered noise. Higher values will blur more noise and kill more detail (Use Structure Tensor view for tweaking)

Geometry regularity = high values will blur more, usually the difference is minor. (Use Normal view for tweaking)

Initial Gaussian Blur = regular Gaussian Blur preformed before other filtering, and will obviously blur the whole image indiscriminately. (Use Initial Gaussian Blur and Structure Tensor view for tweaking)

Iterations = How many times is the filtering applied. There usually isn't a big difference between say Strength 60|Iterations 2 & Strength 120|Iterations 1. (Use Normal view for tweaking)

Gfact = Main tool for creating the edge/detail mask to be excluded from filtering. Higher values may need Noise Scale and/or Initial Gaussian Blur to help remove unwanted noise from the mask. Optimally aim for blue/red lines to cover all your edges and green everywhere where you want to keep detail. If, like petopeto, you don't care about excluding your edges and detail from filtering, stick with the default or other low Gfact value. (Use Structure Tensor view for tweaking)

Spacial Step = Higher values for more detail (Use Normal view for tweaking)

Angular Step = Lower values for less contrast? I haven't found this value particularly useful. (Use Normal view for tweaking)

Gauss Precession = Smaller values for more precise blurring, more detail retained. (Use Normal view for tweaking)

Interpolation =
[Low quality]Nearest------Linear------Runge-Kutta[High quality] (Use Normal view for tweaking)

Fast approximation = More blurring, less detail, fast (Use Normal view for tweaking)

Alt. Amplitude = Alternative Amplitude method to reduce negative effects when using very high amplitude (strength) values. (Use Normal view for tweaking)
asterixvader said:
i was gonna ask the something similar.
is there a User's Manual for this plugin? i'm trying random, high numbers on each parameter, i click "preview", the bar loads and nothing happens, i can't see the image quality improves.
i'm completely lost here.
any example what this plugin can do, or what it is supposed to do?
something like this? http://cimg.sourceforge.net/greycstoration/guide.shtml
I tired looking for some kind of manual for it, but all the results came out to the main sourceforge site and a few others than linked to each other.
well, those who understand this, can tell me why it's not affecting the image i wanna fix?