DeepCShuffle should have feature parity with the base shuffle node. Interface should be same/identical.

Add a basic Multiply node to use in Deep

Consider using an enum to ensure this doesn't happen...

Current conception of how this should work is PMattes and PNoises should be generating inline (ie. B-stream) channels to use as masks, so we're guaranteed a proper amount of samples, and then all grading is done by the DeepCGrade node.

a request we get often, is a proper keymix node for deeps. we do have a gizmo in place but this one create artifacts.

luckily the original source code from the 2d Keymix is in the nuke example files. I started with this node already but if anyone has capacity, I am happy to share (if its worth it....)

2d src code:

https://learn.foundry.com/nuke/developers/13.1/ndkreference/examples/Keymix.cpp

I started already with a node which is in its basics very similar to the built-in DeepFromFrames.

So it would take a 2d RGBA texture and convert it into Deep. With a user defined front, back and samples. Main use case would be smoke, atmos and other typical atmospheric elements.

But i have some issues on how to read the actual 2d data inside the engine. the math on how to distribute and weight the samples is already existing in DeepCConstant and could be taken from there. this matches the DeepFromFrames behavior already.
I would just need some help to get this going.

Further ideas for this very tool would be:

• falloff front and back
• temporal offset from front to back to give it bit more complexity when objects moving across depth. so its not the same textures across all samples per pixel

DeepInPlaceOutputPlane is used in a bunch of the nodes (Add/Remove/Shuffle), and I think this type was added in Nuke 11.2

Any thoughts on how hard it would be to support older versions of Nuke? I'm mostly asking as we are mostly still on Nuke 10.5 probably for the next few months. I think 10.5 is still being patched by Foundry, and it may be worth supporting for a while as the Nuke 10->11 upgrade is relatively difficult (given the Qt 4-> 5 transition/significant compiler changes/etc)

Ideally one run of the CMake build routine would build for all installed Nuke versions >=11.2

Add a basic ColorLookup node to use in Deep

Should have a 3D transform jack and sphere/cube representation in the 3D viewer.

When using a matte node with a side mask on a channel set with data in it, results are unexpected. Should smoothly blend between the existing and the generated, but does not. Blends between mask and generated.

OR, if we're including mask combination features, should take care of that.

I see this is planned in the README \o/

We have one internally and it has proven very useful - it has two modes:

1. Merge by z-depth threshold - the obvious case
2. A dumb "sample reduction percentage" mode, which merges samples to approximately reduce the count by a given percentage - e.g 50% removes every other sample, 10% would remove every ~10th sample. Can be prone to visual artifacts with certain data, but has proven quite useful particularly for debugging/performance diagnostic reasons

We had also discussed some other features which would have been useful at times:

1. Option to to merge samples with similar values (e.g merge all samples where the R/G/B values are identical) - most obviously useful for things like ID channels.
2. Allow combination of these merge options - e.g so you can "merge 50% of the samples which are within 0.1 units", or "merge the samples within 0.00001 in rgba.red and within 1 unit".

Add a basic Gamma node to use in Deep

I would like to do some minor adjustment on the wrapper classes.

mainly i want to inject a vector reference into the wrappedPer... methods.
I would need those to apply matrix calculations and colorspace shifts which using all channels of a set.

I have tested and adjusted all other nodes on a local branch building a DeepColorMatrix node. Are there any objections to do such a thing @charlesangus ?

personally i would prefer this approach then having the get the brothers on each perChannel call.

basically it would look like this with the additional sampleColor.

  virtual void wrappedPerSample(
      Box::iterator it,
      size_t sampleNo,
      float alpha,
      DeepPixel deepInPixel,
      float &perSampleData,
      Vector3 &sampleColor
      );

  virtual void wrappedPerChannel(
      const float inputVal,
      float perSampleData,
      Channel z,
      float& outData,
      Vector3& sampleColor
      );

add the deep equivalent to a ColorMatrix 3x3 node.

Add a basic Clamp node to use in Deep

Each node should have a user guide/manual page on the wiki.

Each page should have:

• Example image
• DAG screenshot
• parameters screenshot
• how-to guide outlining main parameters/use-cases
• release version guide is for

These tools are great. It would be nice to have a keep/remove operator in the DeepCRemoveChannels to mimic the behavior of the standard Remove node.

Plugins have only been built/tested on Centos Linux.

The following plugins are misspelled in src/CMakeLists.txt, causing the build to fail.

• DeepCMultiply --> (DeepCPMultiply in CMakeLists)
• DeepCCopyBBox --> (DeepCCopyBbox in CMakeLists)

build constant node with defined sample count

Need to initialize all the knob variables, strange things happen otherwise.

Add @kingkristo's DeepBlur node from https://github.com/kingkristo/DeepBlur

The toggles black_clamp and white_clamp are defined but not used in DeepCGrade::_validate

In order to match the regular saturation node, the deep one needs the luminance transfer dropdown..

Will compile the DeepC Lib for Windows Nuke Versions.
@charlesangus: What nuke versions shall i compile for?
Newest: 12 + 13?
Shall we bundle them alltogether with Linux or a Release Windows only?

Seems like the foundry introduced a new functionality on ops called OpHints.

if trying to build and link the current source files, it throws an error and breaks. might needs fixing in the wrapper classes.
would need a solution to be compatible with old and new versions.

error below:

/mnt/data/Apps/nuke/Nuke13.1v1/include/DDImage/OpHints.h: In function ‘constexpr DD::Image::OpHints DD::Image::operator&(DD::Image::OpHints, DD::Image::OpHints)’:
/mnt/data/Apps/nuke/Nuke13.1v1/include/DDImage/OpHints.h:89:19: error: expected type-specifier
         using T = std::underlying_type_t <OpHints>;
         ```

despite asking for that ChannelSet in in_channels...

I would suggest to create the python/menu.py via the CMakeFile and to remove the makefile to avoid
the need of appending all the source nodes/files at different places.

If you want i can implement the CMake generator for the menu.py file.

Currently, we're only releasing Linux, so there's no confusion, but presumably once we're releasing for multiple platforms, we'll need zip files named like linux-deepc-11.1v6.zip. Or something.

Add a deep equivalent to 2d HueShift node.

add equivalent deep node to 2d posterize.

Like a Deep equivalent of Shuffle Copy, but since Deep deals in depth samples as well as pixels, it should probably be a bit more like Houdini's AttributeTransfer node.

Modes I see needing:

• 2d input for attribute source, distribute new value along samples, basically like a DeepRecolor but handing just a secondary channel (although now I'm thinking of it, Deep Recolor may already be fine for this...).
• Deep input for attribute source, with tolerance settings for transferring attributes, such as:
  • World radius, based on PWorld attribute
  • Z tolerance, so forward or backward in the same pixel
  • Image-based radius, so within a certain number of pixels in X and Y and likely Z
  • probably also kernels for interpolation, like linear, Gaussian, etc (see what Houdini offers)

To give a bit more flexibility, I want to have different colors supported from front to back.

I suspect this is due to _outChannelSet being a class variable initialized in the constructor, but I'm not sure.

The following nodes fail with /lib64/libm.so.6: version 'GLIBC_2.29' not found:

• DeepCGamma
• DeepCGrade
• DeepCPMatte
• DeepCConstant

This node fails with the similar /lib64/libm.so.6: version 'GLIBC_2.27' not found:

• DeepCPNoise

The version of CentOS 7.6 I'm using seems to have glibc version 2.17.

@falkhofmann - what was the system the latest release was compiled on? CentOS 7? Which devtoolset version?

Hi,

and thanks for open sourcing your work!
I'm trying to build the plugin manually for nuke11.3v4 on Centos 7.7.1908, but our version of /lib64/libstdc++.so.6 only goes up to GLIBCXX_3.4.19, which means I get this error at runtime when trying out the DeepC nodes:

RuntimeError: /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' not found (required by /my/custom/path/to/plugins/DeepCPNoise.so)

Is there anything specific in your code that needs to be using the GLIBCXX_3.4.21 symbols? I was wondering if somehow the cmake file (and the code, if needed) could be updated to work with a lower version of libstdc++.

Or am I getting this wrong?
I premise I'm not an expert of the cmake and c++ toolchains.
I'm build with cmake using this command, since otherwise FindNuke.cmake didn't see to find nuke:

cmake -DNuke_ROOT=/opt/foundry/nuke-11.3v4 -D CMAKE_INSTALL_PREFIX="`pwd`/../install" ..

Thanks!

Valerio

I would like to implement a new node mimicking the 2d math "Add" node.