Re: Rookie having problems with some filter code. Any help?

In article <1134503089.533742.67370@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
jg.campbell.ng@xxxxxxxxx wrote:

<snip for space>

> There's a lot more there than image processing.

Huh? Care to give that thought some context for me? Standing alone like
that, I'm not sure how I should be reading it. A lot more WHAT there?
(and for that matter, where's "there"? Fred's paper? My page? The
gamedev.net website?)

> 1. For a start change
>
> int sharpen_filter[sharp_w][sharp_h]={
> { 0,-1, 0},
> {-1, 5,-1},
> { 0,-1, 0}
> };
>
> to
>
> int sharpen_filter[sharp_w][sharp_h]={
> { 0,0, 0},
> {0, 1,0},
> { 0,0, 0}
> };
>
> and you the output and input should be identical.

Been there, done that, works perfectly - Effectively it behaves as a
verbatim copy operation. If it's changing any pixels' RGB values, my eye
isn't picking up the changes, but I haven't gone to the effort of doing
a value-by-value compare of the original and "new" images to be
absolutely certain.

>
> 2. Print some numbers (a few, a very few) of in and out -- print the
> first ten pixels of input and output of the tenth line in the image and
> let us see that.

I think that can be arranged, but it's going to take a little bit of
time to put it together. Look for another posting with it in the near
future - I'd guess later this afternoon.

> 3. Just guessing, you are extracting 8-bit rs, gs and bs from the Color
> pixel?

Yes. My "homebrewed" "Color = getpixel(...)" routine returns a struct
containing the three 8-bit R, G, and B values for the specified pixel -
just like the Allegro library version. Then my "get[r|g|b]32(Color)"
routine returns "Color"'s corresponding r, g, or b value as a 32-bit
int, also just like the Allegro library.

> And then constructing a Color pixel from the filtered result?

Yep... My "makecolor()" routine is identical in result to Allegro's
"makecol()" routine, just named slightly different. Both simple "repack"
three discrete values into a single RGB struct.

> What is 0*0 -1*0 +0*0 -1*0 + 5* 200 -1*0, ...? Does it fit into eight
> bits?

Good question. Only meaningful answer that I can see being possible is
"Yes, as long as there are no pixel color-component values greater than
about 50 involved in the calculation."

> If that is the case, I don't think 'Normalizer' is of much assistance;

Whether that's the case or not, I'd agree with your statement, since the
value of "1 * <whatever>" is always equal to "<whatever>". A mod256
operation would make MUCH more sense, but it seems to me that it would
also likely screw up the relationship between the r, g, and b values
within the color. (Fred explains that the multiplication by "Normalizer"
is to keep the values in the 0-255 range. But I can't see how that's
supposed to happen when what you get out is going to be the same value
you put in due to the Normalizer value being 1!)

> it should be 1;

Agreed, it should. And is, by the time the summation work is finished.

> incidentally, did you ever initialise it before the summation?

Yep - when it gets declared.
(The line "int Normalizer = 0;", roughly 20 lines into the source code.)

However, you bring up a valid point - one which I've been struggling
with - How to cope with (A) color values that go negative while being
"cooked", and (B) values that overflow the available 8 bits while being
cooked. For situation B, a simple "value % 256" leaps to mind as the
proper treatment. But coping with values that land in "negative-ville"
as a result of being cooked, whether they are or are not possible to fit
into 8 bits, is something that has me completely stumped.

> Unless you know what you are doing,

Heh... I thought I made it clear that I'm just barely getting started on
the process of figuring out how to know what I'm doing! :)

> do image calculations in float or double and *then* normalise and convert
> back to whatever.

Been considering that concept, but no matter how many digits to the
right of the decimal, I can't figure out "the right way" to cope with
numbers that go negative in the "cooking" process.

Thanks for the attempt so far, anyway!

--
Don Bruder - dakidd@xxxxxxxxx - If your "From:" address isn't on my whitelist,
or the subject of the message doesn't contain the exact text "PopperAndShadow"
somewhere, any message sent to this address will go in the garbage without my
ever knowing it arrived. Sorry... <http://www.sonic.net/~dakidd> for more info
.