I am trying to implement a ‘depth differences’ technique where if adjacent pixels (in the zDepth map) have a higher contrast than a threshold value then they are turned black, which will hopefully create nice outlines on objects.

Is there a way either with materials or compositing to achieve this?

Simply put, how can I get the values of various pixels and compare them?

Thanks

Renderman has Image Shader [renderman.pixar.com], witch can manipulate pixels value, but Mantra doesn't. Mantra have fog shader, where some sort “post-processing” is possible, but it's not the same as PRman Image Shader.

You could try to do this in COPS.

http://www.sidefx.com/docs/houdini14.0/nodes/cop2/depthdarken [sidefx.com]

Mantra now allows custom pixel filters in the HDK, which take the data from primary rays sent from the camera and generate final pixel values. The example code, VRAY_DemoEdgeDetectFilter is the code for the edgedetect pixel filter, which sounds vaguely similar. If you literally just want an edge detection filter applied to renders, you can just set Pixel Filter to “edgedetect”. There are some not-yet-documented options for it, which I could add documentation for, if it needs tweaking from the defaults.

ndickson
Mantra now allows custom pixel filters in the HDK.

Funny enough I've just put into my blender this new VRAY_PixelFilter.h with CVEX_Context.h… Still struggling about details like how to split data (give one pixel only its samples?), but overall impression is great. It makes possible many interesting effects.

SYmek
Funny enough I've just put into my blender this new VRAY_PixelFilter.h with CVEX_Context.h…

If you can get a VEX-based pixel filter setup working, that'd be pretty sweet. I stopped short of that, because I wasn't sure how to get it to interface in a user-friendly way given the time constraints, but it'd be really cool. Ideally, there'd be a multi-line VEX editor in Houdini for it and everything, with an option to point to a file, etc. The big unknown is how to be able to precompute things, based on the options, both so that Mantra knows the filter width, (to know how far it needs to expand the sample range), and so that the VEX code can use precomputed information for complicated filters. If you have any ideas, please feel free to share!

Still struggling about details like how to split data (give one pixel only its samples?)

I'd split just on the output data, i.e. the output pixel colour/value, and give an integer variable named something like pixelnum.

Any filters with a width > 1.0 may need more than just the samples corresponding with rays sent from inside each pixel. For some filters, it's amazingly complicated just to figure out in advance how big the filter width needs to be, and at filter time, where samples need to be read from. The edgedetect example provided sort of demonstrates a medium difficulty case in that respect.

Of course, ideally, people wouldn't have to compute indices into the sample data themselves, based on the pixel, because it's a huge pain, so maybe that could be abstracted out a bit, so that VEX code can access the data relative to the pixel more easily. If you had a function that was something like: RET_TYPE getsample(pixelnum, sx, sy); where sx and sy are sample coordinates relative to the corner of that pixel's samples, that might help a lot.

I also tried to have it use a lot of the features, like accessing other image planes, so that there are examples of that. If you'd want the VEX code to be able to do that too, it'd be another consideration.

Thanks for thorough answer and encouraging. Yes, demoedgedetect gave me some tough moments I was trying to think about Cvex filter without extending VEX, but it left me with naked arrays and handmade indices for now.

I'm planing to repack source as small array per pixel - extended by user specified width as it's now for built in filters (-w x).

But I agree to make it more friendly some precomputed object or function would be handy. I'm not sure if I (HDK end-user) can make such setup, but one could try to make something similar to UT_PointGrid from full source (all samples) available in cvex filter (as a third party I think I could try to send all-samples array and make vex function precomputing static object similar to pcopen).

Then I could refer to exact pixel or neighbours' samples easily, query proximity etc. What would be even cooler is to auto precompute additional channels like integral of the grid, gradients etc. The cost shouldn't be high and most advance filters would benefit.

Ideally this should be a function similar to texture() but referring to underlying VRAY_Imager with all rasters and with special indexing in destination space. It could return either an array of samples or computed result of an operand like sum, min, max, std-div, avarage etc.

Not sure if this is worth efforts.

I try to write pixel filter, similar to cryptomatte for exporting ids and weights of coverage in special pass.
Filter should use the weights of sub-pixels from main image for inner computation to correspond the “beauty” pass.

Is it possible to get weights of sub-pixel data from filter of “beauty” image, or i should recreate this filter (gaussian or blackman)?

And where can i find native houdini implementation of gaussian and blackman filters?