Spring RTS Engine

Fizz... to put it in lamemans terms...

Greyscale is NOT 8 bit.. so working in it is not as limited as you think..

when you save into an image format:
256 colors is 8 bit
a huge amount of colors 16bit

The range of colors determines the range of greys...
8 bit is not enough because it has 256 colrs
16 bit is better and while I am NOT sure, I KNOW it has a huge number of colors


Weaver, true 16 bit colors I believe is 48bits is the is format you would need for that... although the highest we get in images(to my knowledge) is 32 bit which uses part of the image as an alpha channel.

48bit is normally only useful for scanners and cameras as it allow plenty of exposure correction. What would be useful for us is to be able to edit more than 256 levels of grey as it would avoid the obvious steps in some maps. We don't need to wait for a new map format either, the curent one 16bit in one channel ie 0-65535. What we need is a method of creating them and getting them compiled.

The solution I an considering is to mix an 8bit per channel 24bit image at compile time, with each channel having seperate weighting and smoothing.

eg. You could have your old height with high weighting and high smoothing, then you can mix another channel at lower weighting to sharpen up the peaks and edges where you want them and yet another for tiny features as small as puddles.

Weaver wrote: What would be useful for us is to be able to edit more than 256 levels of grey as it would avoid the obvious steps in some maps. We don't need to wait for a new map format either, the curent one 16bit in one channel ie 0-65535.

but we can, that is what I am saying. If it is a black and white image we can work in 16bits.. I can see I am going to have to do a black and white 16bit image for a height map for this. I may be wrong but I am sure it is easy to test.

I probably should clarify when I am talking about greyscale I am not talking about the "greyscale setting" I mean an image with no saturation applied. Is it your experience that it still reduces to 8bit color?

I will tell you right now that under the RGB color system, there are only 256 shades of grey available represented by the numbers 0-255.

So it's effectively 8-bit.

webbie did you EVEN read the explanation I posted about HOW the colors are determined.

What you said is like saying you have red green and blue paints so you will only have 3 colors.

Weaver wrote: What would be useful for us is to be able to edit more than 256 levels of grey as it would avoid the obvious steps in some maps. We don't need to wait for a new map format either, the curent one 16bit in one channel ie 0-65535. What we need is a method of creating them and getting them compiled.

The solution I an considering is to mix an 8bit per channel 24bit image at compile time, with each channel having seperate weighting and smoothing.

eg. You could have your old height with high weighting and high smoothing, then you can mix another channel at lower weighting to sharpen up the peaks and edges where you want them and yet another for tiny features as small as puddles.

I like this idea as it seems the easiest way to make a more detailed height map.

Smoth: do you know any editor that lets you edit a 16 bit channel? I haven't found one yet...

photoshop.


Image-> mode-> 16bits/channel

Android_X wrote:

Weaver wrote: What would be useful for us is to be able to edit more than 256 levels of grey as it would avoid the obvious steps in some maps. We don't need to wait for a new map format either, the curent one 16bit in one channel ie 0-65535. What we need is a method of creating them and getting them compiled.

The solution I an considering is to mix an 8bit per channel 24bit image at compile time, with each channel having seperate weighting and smoothing.

eg. You could have your old height with high weighting and high smoothing, then you can mix another channel at lower weighting to sharpen up the peaks and edges where you want them and yet another for tiny features as small as puddles.

I like this idea as it seems the easiest way to make a more detailed
height map.

Arrgh illerate people...

let me make this perfectly clear:


If you read my LENGTHY explanation you would know we have more colors then just 256. Even if you are using red paint... think of it as water colors. If the red paint is diluted you get PINK not RED.

See the above image? see how there is more then just rgb colors. You have any range available, it is not as simple as RGB colors. I can see that a simplyfied explanation is wasted.

There is LAB, RGB, CMYK. You are not using exclusively the rgb pallete:

Argh weaver is actually completely right... when photoshop converts it all to grayscale you end up with a possible 256 different values of gray.
What you're showing is only a dialog that converts different color palettes to RGB channels, which in turn are converted to grayscale which end up having 256 different possible values.

Smoth, as soon as I enable 16 bit color all the filters are disabled... or is photoshop 7 too old in that case?

Weavers method could work, but it needs changing the mapconv I think, and would really not be easy for the mapper.

Finally, that is all I wanted to hear!

According to everything I have looked at it was the contrary. Although, I do not understand this one part. If what weaver is saying is correct...

Let's assume I am working with an image. I am playing with all my colors etc, how is it that I can edit it and save it as a 24 bit image or 32 bit image when all I am able to paint in is rgb values?

I know the monitors are limited to RGB but I always figured that IF I was editing an image then it was not in actual RGB untill I saved it. Thinking on that perspective how is it that the images editing on a machine do NOT display a massive ammount of loss?

I am looking at what we are talking about in here with shock and disbelief.... I can actually see the line where 0,0,0 and 1,1,1 are and even when using c,m,y,k. I think this is because the color conventions of HSB, LAB, and rgb have maxes and mins within [0,255]. However, I have seen alot of posters with large grey to black gradients and I would have noticed this line. So somewhere we are missing something. I am going to dig aroun and see what is missing. I am sure there is a true 16,24 or 32 bit editor. If what I am looking at is true then photoshop is not worth learning.

smoth, do you really not understand the RGB scale?

One RGB scale covers every range of colors from black to white to pink to red to ever intermediate color you can think of. Annoyingly this means that you only have a maximum of 256 greys to work with in greyscale, even if you compile in a high definition RGB environment

All RGB colors in the greyscale range have equal RGB figures, for instance 60, 60, 60 is a greyscale color, 245, 245, 245 is a greyscale color, 0,0,0 is a greyscale color. However, 30, 50, 78 is not, and never can be a greyscale color. What this means is no matter how much you play with your standard high end RGB image you can't have more then 256 shades of grey, and therfore the best RGB to greyscale conversion we can possibly make is an 8 bit greyscale image.

This really has nothing to do with color theory or any of that other fun stuff. It's cold hard computer math.

What weaver suggest is basically:

height = redvalue * redfactor + greenvalue * greenfactor + bluevalue * bluefactor

redfactor = 255 * 255
greenvalue = 255
bluefactor = 1

Or other factors...

This way you can do have 2 ^ 24 number of height values... (spring uses only 16 bit though, but you can see how it works)

SwiftSpear wrote:smoth, do you really not understand the RGB scale?

One RGB scale covers every range of colors from black to white to pink to red to ever intermediate color you can think of. Annoyingly this means that you only have a maximum of 256 greys to work with in greyscale, even if you compile in a high definition RGB environment

ORLY???

the color conventions of HSB, LAB, and rgb have maxes and mins within [0,255].

In math what does [A,B] represent?

SwiftSpear wrote: All RGB colors in the greyscale range have equal RGB figures, for instance 60, 60, 60 is a greyscale color, 245, 245, 245 is a greyscale color, 0,0,0 is a greyscale color. However, 30, 50, 78 is not, and never can be a greyscale color. What this means is no matter how much you play with your standard high end RGB image you can't have more then 256 shades of grey, and therfore the best RGB to greyscale conversion we can possibly make is an 8 bit greyscale image.

This really has nothing to do with color theory or any of that other fun stuff. It's cold hard computer math.

God this, pisses me off. READ THE POST I MADE EARLIER...

I stated that the greyscale range for 8-bit image editing was this: [(0,0,0),(255,255,255)] I am a programer I can bloody read binary. I KNOW where the number COMES FROM can convert it to hex if I need to. I cannot believe you, read the post I made earlier. I know you are not a condescending person. I explained it in BINARY for CHRISTS SAKE!


I found my answer btw... I had made the assumption that our current editing tools were up to 16bit image editing. I am SHOCKED they are NOT there. However, it has come to my attention that CS2 can and does correctly handle 16bit images. Yeah, My assumption about photoshops progress towards 16,24 bit editing was wrong but do not have the audacity to tell me i cannot understand computer math. Christ you have no idea how much that pisses me off.

photoshop CS2 can edit 16bit images... must go shopping...

*EDIT* now that I am a bit more relieved now that I have vented... lets recap shall we:

I explained 8 bit colors and show you people how to read the binary that LIMITS the effective color range to [0,255].

I explained how 16 bit images do not have this limit....

I ERONIOUSLY assumed that PHOTOSHOP was a true color editor. I was WRONG I acknowledge that I should have tested it before assuming photoshop7 was up to the task.

I did some looking online... lo, photoshop cs2 can do work in 16bit....
I feel better after venting my frustration. you know it took me about 45 minutes to write a simplyfied explanation of binary. I have NO idea where you drew color theory from. Do not disrespect me again, I have respect for you however diminished after that post I still know you are a cool guy swiftspear.

*end edit*

mmm, we're on the same page. I wasn't aware there was a software suite that supported higher then 8 bit RGB color resolutions ATM.

[edit] I didn't mean to be condisending. I sounded like you were arguing that you could generate higher then 8 bit greyscales off an 8 bit color depth RGB scale.

SwiftSpear wrote:mmm, we're on the same page. I wasn't aware there was a software suite that supported higher then 8 bit RGB color resolutions ATM.

[edit] I didn't mean to be condisending. I sounded like you were arguing that you could generate higher then 8 bit greyscales off an 8 bit color depth RGB scale.

not at all I am just a bit upset about

A: I typed a nice long post about it which was ignored... however, DO read my post you will see that I have a good understanding of rgb colors. I do not have a good understanding of 16 bit though.

and

B: that I feel cheated by photoshop.. I was an ass for assuming that it did have 16bit. I saw it in the menu I just have not needed to use it yet. I was an idiot for no double checking.

That and I have been up all night trying to think of ways to get things done so my mod can work better in spring.

16-bit color features
Without a doubt, the most major surgery done to Photoshop CS was in the area of overhaul features, specifically the integration of real 16-bit per channel color support. Now, obviously, Photoshop had some degree of 16-bit support in the past, but it was so limited that I never would have previously referred to this application as a 16-bit image editor. You could open 16-bit files; you could apply a few adjustments; but you could never do anything in the way of real image manipulation before.

I have Paint Shop Pro X which does have limited support for 16 bits per channel, can even save them in TIFF. But as I said the support is not complete, some built in filters work, painting doesn't! I was looking for a solution that did not require expensive software. Its not ideal or particularly practical but with a little practice we could make better maps with it.

I see enough expensive solutions at where I work.
http://www.quantel.com/site/en.nsf/html ... enDocument

Ok, first an admission: I didnt really read this whole thread.

So FWIW

The current map format supports unsigned 16bit heights.

The only way to get mapconv to read your long heights is to use a 16-bit RAW file for the heightmap.

Teh Gimp does not support the RAW format -nor- 16-bit channels. Apparently PS doesnt do 16-bit channels either [from above].

Now the real pisser. While 256 distinct height levels is a bit to few, 256^2 distinct height levels is totally overkill given the low-res heightmaps we use. [IMHO]

the reason I am disagreeing with the r+g channel =16 bit is that the color channels from what I have read and experienced work on an ADDIDITIVE blend mode.
I don not understand how combineing two 8bit channels will yeild a higher value as the two channels blend when merged(is this the right term).

I still have not slept btw. I am really interested in this conversation..

Weaver, CS2 will support 16bits perchannel with many if not near all features enabled. Please prove or disprove me. I am dying to know which way is correct. This topic has fascinated me I have been reading everything I can on the subject and still not concrete answer.

The one thing I am pretty sure about is that two channels does not equal one 16bit channel because again the Program one is using utilizes 8bit mode. I am still pissed about that but anyway.. what say you weaver?

smoth wrote:the reason I am disagreeing with the r+g channel =16 bit is that the color channels from what I have read and experienced work on an ADDIDITIVE blend mode.
I don not understand how combineing two 8bit channels will yeild a higher value as the two channels blend when merged(is this the right term).

In practice or in theory?

In practice you could use 8r+8g=9bits (as you said 'additively'). The reason that (in practice) this wouldn't work to produce a useable '16 bit channel,' is how the hell would you create the thing? While you could conceivable do everything 'below sea level' in the blue channel and 'above sea level' in the green- and get effective 9-bits of resolution; go ahead and try to do r[0-255]*g[0],r[0-255]*g[1],r[0-255]*g[2] ... r[0-255]*g[255] (Which would yield 16 bits of info).

Now go sleep