Check it out:
b = bitmap 256 256 color:(color 20 20 20) filename:"C:\ est.bmp"
display b
save b
The bitmap’s color should be a flat gray, but it has very slight noise to it. However, this noise is ONLY apparent in the saved bitmap, OR when you save it from the Display dialog that pops up (it doesn’t seem to be a compression problem). However, the problem is NOT there in the Display dialog. Where is this noise coming from? Right now I have to get around it by taking a screenshot of the display dialog and cropping it in photoshop to get the non-noisy bitmap- I don’t understand why this noise only appears when the bitmap is saved (using any method). Generally this noise would be a minor issue, but I’m doing some image processing in Max that makes it very apparent and breaks what I’m doing (since even a shift of a single gray value will throw it off).
BTW, I’ve also tried using [20,20,20] instead of a color, and using hdr:true, neither of those did anything.
try disabling true color dithering in your max preferences (rendering tab, I believe)
( off-topic: I really hate it that the post form doesn’t enable until after it loads the ads. Had to wait half a minute for it to load from the external server. )
As Richard pointed out, there is this ancient option to dither true color. The reason: Back in Max 1.0 days (and even in 3d Studio R3 for DOS), the renderer was using 16 bits per channel internally (64 bit for RGBA), but no file format was able to save the data. So, in order to avoid heavy banding when saving to 32 bit formats like TGA, the dithering was included. It would try to simulate the real color from the internal buffers in the final image. Obviously, with the advent of PNG and especially OpenEXR, this stopped being a big issue, but the setting remained and most people don’t even know about it. I remember getting reports from highest levels of the Max developers team asking me why my icon making script I wrote for Max 3 was causing strange color changes each time it resaved an icon library – turned out to be the same cause… If you are saving to floating point or higher than 8 bpc images, you can safely turn the true color dithering off. There is also the 256 colors dithering which nobody really uses nowadays since neither GIFs nor FLI/FLC files are supported or used anymore, but in those early days it was great to have in order to get animations with enough shading to represent what was really in the scene.
I understand the need for this when rendering, but why on earth is it messing with the bitmap values that are 8-bit anyway? I’d call this a bug…
– MartinB
Because 8 bits per channel is still only 256 levels. I’m sure you’re familiar with the “make a greyscale gradient from black to 25% grey, now look at it”-test of spotting banding. If you can see the banding, well, that’s where truecolor dithering comes in. One could argue that when saving to 16bit (65536 levels) dithering shouldn’t be applied, but even then, 16bit is much less than the 32bit space usually rendered in internally.
Well it’s labeled “TrueColor Dither”, so I’d imagine it does exactly what it’s supposed to
What I would call it, however, is a misplaced control. This control, imho, should be somewhere in the render output options of the render scene dialog so that it can be more easily found and toggled where appropriate.
I would argue that the code computing the gradient should do the dithering, not the software framework used to handle the bitmap.
After all, if I create a gradient ramp with MAXScript, using 8bit values, how does the dithering know how to dither? I thought dithering is the distribution of the error between the intended value (e.g. 25.678) and the possible pixel value (26) to the neighboring pixels? So how can it do that if it does not know the intended value?
I would understand the dithering if I would store float values into a bitmap and then save as 8bit…
– MartinB
Wow, that’s, uh… I can’t quite find the word, but thanks! Bobo, can I make a suggestion and put this somewhere in Help? Us in the Games world usually don’t worry about rendering much, and working with bitmaps I wouldn’t consider rendering. Even though it is obvious what I was seeing dithering, it never occured to me it was… would have never guessed to check the render settings since I don’t consider ‘save bitmap’ rendering, I would have specifically had to search for ‘Dither’ in help and take a stab by turning it off. This can be pretty intrusive, IMO, if it is automatically tinkering with what I have between the screen and on disk- I would definitely suggest documenting this somewhere. Thanks for the help, you two.
I remember dealing with this issue when I wrote LightRigger, and there’s a way to script around the problem. Here is the code in your example:
(
b = bitmap 256 256 color:(color 20 20 20) filename:"C:\ est.bmp"
display b
local OldDitherSetting = rendDitherTrue
rendDitherTrue = false
save b
rendDitherTrue = OldDitherSetting
)
Access to the rendDitherTrue and rendDither256 settings is described on the “Renderer Preferences” page in the docs…