@hifred
ZSurf4 works with 32 bit images…
Sorry, I meant something else here. Ordinary image displayed on a computer have 3 colour channels + possibly an Alpha Channel. All four of these channels have 8 bit, meaning 256 levels of colour and in the case of the alpha channel 256 tones of grey. Together that’s 32 bit.
What I mean is 16bit per individual channel. Images with higher bit depth can store more colours and in the case of displacement maps a lot more tones of grey. Smoother gradients result in smoother displacement – given the input mesh is dense enough.
Zsurf is a simple utilitly which has been written at a time, when even Photoshop couldn’t handle high bit depths. It’s a safe bet that it can’t handle higher bitdepths than 8.
:o)
I have made the image in Photoshop and I have kept him in the tif format (qualitative).
I use Heightfield, it is important to specify in Number of sample points size of the image. Result not very much:
And now it is necessary to use FitSrf with some accuracy and result already good:
But to excellent result - we apply Rebuild
However, why in general artifacts appear?
@schultzeworks, @RichardZ, @wim, @nathanletwory, @pascal, @Helvetosaur
1 Like
Zsurf does handle higher bitdepths than 8 internally. Getting around the 8bit limitation is one of the main reasons for its existence.
I would imagine any internal processing would be done at higher bit resolution if its done on any computer built in the last 30 years. The question is does the result get stored in memory or on disk at a resolution higher than 8 bits
Hi jim,
I had actually hoped you wouldn’t read this :o) – I did not mean to sound disrespectful.
Ok, but you obviously still have to deal with the limitations of the 8bit input image.
You probably will yield more smoothness, but one can not swindle in additional detail by internal resampling.
Well, this cellulite looks like 8 bit to me…
This is true, but it is only a problem where the gradient is fairly flat.
You can also create images within Zsurf so those are high resolution from the start . The Text function will make very smooth surfaces R.3dm (775.8 KB)
I don’t know what that texture is. It doesn’t look like the banding you get from 8 bit. Might be some sort of dithereing.
i probably cant answer that to the fullest, but images are built up out of pixel and have a limitation through the amount of color differences the image can save, as pointed out here which has to do with the bitdepth and represents the color resolution.
the best solution without having to fitsrf too much and too rebuild i would suggest to keep the resolution of the image high in relation to the heightfield, so the jpg you showed on top is of course too small. after importing it into photoshop resizing it and using gaussian blur in 32 bit then reducing it back to 16 to import it into rhino, the image becomes instantly smooth with the best result using interpolate surface through samples. here both images have 80 x 80 points the left is the low resolution image on the right the high resolution.
of course if you turn up the number of points during the heighfield command it will try to get closer to the limitations of the image and will create a though finer but still rough surface. here 800 x 800
I would create a very high resolution height map instead of the low resolution you used. (I think the small dimples look like the separate pixels.) There probably will be still some artifacts, but the sampling will be more accurate.
@RichardZ, @nathanletwory, I use the size 1000x1000, I experiment with depth of color (I did as has told RichardZ) - result all the same bad: 
i described 800 x 800 points not pixel for a rough but precise surface, just in case that was not clear. all the numbers i described where points. take a high resolution image (i took 1400 x 1400 pixel at 125 x 125 mm for the heightfield) and decrease the amount of points in the heightfield command try 80 x 80 points for the surface just to see the difference. the result is a smooth surface.
If you are using the jpg format, the texture you are getting is due to the jpg compression scheme
To avoid the texture use an uncompressed omage format
1 Like
it makes a bit of a difference but its hardly relevant by the time you have reached a generally acceptable surface. in both cases below using 800 x 800 sample points an unwanted texture is being created. left the extra jpg artefacts, right the same image with a none compressed 16 bit PNG image.
below the same comparison with 80 x 80 points, left the jpg and on the the right the png the difference is already marginal.
i suggest to take an image which has a high resolution and lower the points till its smooth as you want.
That’s right. Converting the jpg to a different format doesn’t get rid of the jpg artifacts. He should not use jpg for storing the images.
saving a jpg into another format is not what i described. if one uses an acceptable image in resolution its not relevant using a jpg or an uncompressed format due to the above described reason.
I use the image 1200x1200, manipulations with a depth of color, preservation in TIFF, I specify the size 80x80 in Rhino. Result all the same with defects:
looks better already now just raise the resolution further to 1400 x 1400 or more if needed
and you are probably there.
I dunno - it seems to me with a smooth image and control point heightfield, setting the points to match the pixels ought not to show artifacts like the lines in Modeler’s images above. So far I do not see anything in the pixels of the image that would account for the lines through the middle of the result-
-Pascal
At the image 2000x2000 - it is it seems normal…
But it is somehow inconvenient 
@pascal, I about the same.
Have you tried the edit → rebuild command to get more control points into the flat plane?
I did not see that in the prior post thread. I have better luck with displacement when I re-build – and add LOTS of extra U and V’s.
I tried to replicate issue and i found that png don’t work with heightfield but i used 16bit tiff - while playing with displacements and similar things 16bit workflow is crucial cause of amount of stored data. Small bak and forth with render mesh and looks pretty nice i think
After some more tweeking:
3 Likes