I've seen ways to convert greyscale images to .bum maps (using Photoshop or PSP), but how would you convert .bum maps to greyscale images in a way consistent with Poser?

Bum maps can be opened in Photoshop when you change the extension, if I remember well, to .bmp . What you get is a kind of normal map, or a coloured bumpmap in photoshop with an added dimension. Turning this into greyscale is not easy I guess as greyscale bumpmaps cannot do what normal maps, or pseudo normal maps can.

I wrote a utility called IMAGEDIT that can convert .bum into .bmp . It is in the freestuff.

That's my sticking point, Aeneas. I understand greyscale bumpmaps and I mostly understand normal maps, but finding a way to convert the former to the latter, well, that's an interesting process. Although Poser bum maps don't usually show it, you can have multiple level-ups/downs (as it were). So, you can get a pyramid sticking in/out of a face by stepping up multiple times then stepping down multiple times. This leads to a problem. How does one decide from the normal map when the highest level is achieved (since all unchanging levels are given by some median color)? And, how does one decide how much an upward/downward gradation changes the amount of gray for the bump map (number of pixels, color strength, or both)?

There's no way to really convert it back, although I have some theoretical information that may (or may not) help. First, it depends on how it was made. If a PC version of Poser 4 (or Pro Pack) did it, then it's got a couple of reversed channels. See: http://www.morphography.uk.vu/bumpmaps.html That's useful to know to first "correct" it. After that, the process for manually making a P4-style bump map is: The steps are: 1) Select blue channel 2) Fill with black (100% opacity) 3) Select green channel 4) Emboss (Angle: 90, Height: 1, Amount: 100) 5) Select red channel 6) Emboss (Angle; -30, Height: 1, Amount: 100) 7) Select RGB channel ---------- Theoretically, it may be possible to tweak the channels to get back more to what a grayscale image of it would be. Theoretically. :-) bonni

In Poser bump maps, the bvlue channel has some sort of special meaning connected to transparency or something like that.

No, not at all. The Blue channel is always BLACK. It is unused, unlike other normal maps where it represents direct lighting from above. A proper Blue channel would get me 99.999% of the way back to a bump map! ;) elizabyte, I know the process from bump to normal for Poser (and I am aware of the Windows gotcha). But there is absolutely zippo information on the inverse process on the internet. I did exhaustive searches of both it and my stack of 3D books. Nothing, nada. Might be time to look for pure 2D image embossing algorithms to see how to invert the process. I agree: theoretically, it's possible, but there are many caveats to the process - especially with ill-formed Poser bum maps extending directly to the edges (which makes the process even less appealing). :0) The other problem is that there is no "inverse-emboss" algorithm. I have yet to encounter one (and I did an exhaustive internet and book search on that as well). It is obvious that CL has such abilities, but then they developed the bum map code to begin with. So, going the other way is probably not too much of a difficulty for them. Oye vay. Who's stupid idea was it to use normal maps in the first place...

Attached Link: http://www.buckrogers.demon.co.uk/software/ppp.zip

As regards the blue channel in Poser .bum files., sorry :: I have heard different things from different people.

Message edited on: 02/02/2005 01:51

Addendum: elizabyte: Is it really -30 (and not 0)?

Anthony, I have your program, but don't see how to 'properly' convert the bum map to bmp. I can "Convert from Poser bum into Level 15", but this does not look right using the standard "Male Muscle Bump.bum". Of course, this is Windows, so that could be the issue - but doesn't look it. Anyway, I need to do this programatically (and commercially), so use of dlls is out of the question unless they allow commercial use and can work inside of another app = C4D). elizabyte: yes, you are right. -30d.

Conversion from .BMP to .BUM is lossy. That includes: if you add the same amount to every pixel of the original .BMP file, the resulting .BUM file is unchanged. And the last (units) bit of each pixel of the original .BMP file is thrown away. So, back-conversion won't always get the original .BMP map unchanged. Or, if someone made the .BUM map by a special process that makes height differences more than 254, the resulting height map could not be represented by a .BMP file properly.

Bum files, normal maps and are derivatives of a grayscale (=level) map. The reverse of a derivative is integration, so it should be possible to get the grayscale map back by integrating the map over u and v in the respective color channels.

Which is what my program ppp.zip (otherwise called IMAGEDIT) does. Ordinary mathematical differentiation followed by integration is also lossy: sin(x), sin(x)+4, sin(x)-8888, sin(x)+.0000234, etc, all alike differentiate to cos(x), and thus the result of integrating cos(x) cannot be specified any closer than sin(x)+C .

Ooooh. Calculus. My favorite! Couldn't it be chaotic or fractal in nature. ;) Anthony, that makes sense. Yes, I would figure it to be a lossy process in both directions (you are losing levels in the normal map and then trying to reconstruct it). On a hopeful note, applying Emboss to the bum map using reverse angles (-90 and 150) retrieves some of the level map. Of course I can't retrieve it completely, but this only requires an Emboss algorithm similar to Photoshop's. Any problems with that approach? :)

As long as you're using it as a bump and not for displacement, it doesn't matter if you lose the levels. After all, the rendering engines usually use partatial derivatives to determine how to bend the normals from a level map. BTW, this is the motivation for normal/bum maps in the first place: Moving calculations out of the rendering process and storing it in precalculated form in maps.

Won't be used for displacement. Anthony, where in your code do you do the conversion? Again, I'm not certain about where it's actually done in the app, so it makes it difficult to find in the code.

It is possible to revert a BUM to grayscale. There is a plug on the Mac Classic version of GraphiConverter that will convert a BUM to grayscale in any format that you like. The real trick is nullifying the emboss. Other than that, it's a straightforward (done backwards) process to convert it. Since an emboss can't be perfectly undone, the process averages the red and green channel after de-embossing and then writes that to all three channels. Once that is done, the grayscale is inverted (provided that the grayscale was properly inverted in the first place) and saved. The result is a little fuzzy, so sharpening might be needed to make it more usable. Keep in mind that BUM isn't a real format. A BUM can be any RGB file format, BMP, PICT, TIFF, JPEG, etc. The extension is just changed to give Poser 4 a proper handle on it.

Well, I have two approaches so far. One involves 'de-embossing' the image. This will require proper embossing code - so far nothing useful found. My programming arena does not include 2D graphics much - last time I played with 2D graphics was DOS Modes. :) The other involves looking at the normal vectors as a function of 'lighting' or the directional change of the normal away from the median (pointing directly off the image face) in each of the lighting directions (X and Y). I don't see how and why integration/derivation plays a part in the process of creating/converting normal maps - even if they are of the type formed from hi-res geometry. Unless someone is going to provide technical references to this process and why it's relevant, it isn't worth pursuing. I wouldn't mind going with the normal vectors (vector math I can handle), but how to interpret normal, normalized, direction vectors as height changes is another story. And, yes, I realize that BUM isn't a real format, just Poser's odd version of a normal image map (no matter the file format utilized). Why couldn't CL/Metacreations have used industry standard normal maps (whether they be object/global/tangent space)? Do they have something against standards and normality? ;)

Why couldn't CL/Metacreations have used industry standard normal maps (whether they be object/global/tangent space)? I don't think at that time existed something like a standard for normal maps.

Maybe 'standard' is too strong. But the overall consensus is that, no matter the space used, red encodes X, green encodes Y, and blue encodes +Z normal alignments. This has been the 'standard' explanation on every site that I've visited concerning normal maps. If, indeed, Poser uses a 30d emboss for one of the directions, they are already off-kilter with sanity. What is wrong with mutually perpendicular axes? I'm still getting no closer to a coding solution for converting Poser BUM normal maps into greyscale bump maps...

In Poser, red is X and green is Y, just like in other programs too. Blue is not expicitly necessary, knowing that the normal vector is normalized Z can be derived from the other two.

Either way, it still doesn't get me closer to a coding solution for the conversion. There are no "How to convert Normal maps to Bump maps" books (nor are there any easily finable books containing information about normal maps). I have "Computer Graphics: Foley et al". I have "3D Computer Graphics: Watt". I have "Graphics Gems I-IV" and "Game Programming Gems". None of these great tomes (and they are BIBLEs of computer graphics programming) even mentions the word "normal map"!!! So, where does that leave me for practical programming solutions?