16 Bit Image Support? about texture-synthesis HOT 11 OPEN

Yes, currently all operations are done in RGB space, though I think you might be able to get what you want using the repeat transform feature? https://github.com/EmbarkStudios/texture-synthesis#api---08_repeat_transform

from texture-synthesis.

Gonna try it! So sorry for delayed response.

You're saying to try if repeat transform will operate on 16 bits?

I can do it straight on the normal maps, but the way the images are blending aren't really proper.
I think... ideally ... the images would transform with a slight fall off and height blend as they draw in.

Thank you Jake!

from texture-synthesis.

+1. It would be great if the channel depth could be made a parameter of the model (using generics). Common depths are u8 u16, f16 (see half) and f32.

from texture-synthesis.

Got the chance to test it with repeat transform - so -

It works amazing with for 8 bit maps. I did it with an albedo map and repeat transformed a normal map and it produced really nice results. Some of it was a littile "tiley" and the pattern seemed to grab a pretty basic noise that didn't necessarily catch some of the flow of the albedo. (tree trunk)
Overall though the results were very nice.

However repeat still produced an 8 bit map for the height map. :(

from texture-synthesis.

I've been thinking about this a little more... Is there a reasonable way we could parse the .xform file?

If it is simply a coordinate system defining the loocation of the original pixels, we could use a simply image manipulator like pil or imagemagick to transform pixels of a new image.

Assuming it's something like
[5,1] //Copy pixel at 5,1 to 0,0
[400,30] //Copy pixel at 400,30 to 1,0
[50,24] //Copy pixel at 50,24 to 2,0
etc.

It would be pretty simple to write something to match the transforms. Potentially we could even use a pixel process in Substance Designer.

Is there any documentation on how we can read an xform file?

from texture-synthesis.

Or simply save a 2d transformation map in float(stmap in nuke). But that may represent some extra work if there isn't any code using float at the moment.

from texture-synthesis.

Decided to dig into the code a little bit... Is it correct to assume that most of the actual processing is happening at 32bits, and just normalizing out to an 8 bit image at the end?

from texture-synthesis.

I respond because nobody on this but I think the computation, neighbours etc is done at 8bit to save ressources.

from texture-synthesis.

Thanks jan - appreciate it. I'll dig into it some more. Would be pretty easy if most of it was done and just normalized at the end.

from texture-synthesis.

Sorry but is there anything plan for this?
-without float or 16bit output our best hope would be to use the the .xform file which certainly contain ids for the maps and their pixel position but its structure is probably custom and I can't write code for that, especially in rust... arvin did you made progress on this?
thanks.

from texture-synthesis.

Unfortunately I hadn't gotten a chance to mess with this.. Sorry jan. :)

I found a simple solution in the mean time - I used affinity designer which lets you do an operation on multiple layers at the same time. Similar to painter - working at the material level, but able to use all ps tools - clone, heal etc.

from texture-synthesis.