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


"Don Bruder" <dakidd@xxxxxxxxx> wrote in message
news:439f9bd5$0$95973$742ec2ed@xxxxxxxxxxxxxxxxxxxxxxxxxxx
> In article <dno3mv$bae$2@xxxxxxxxxxxxxxx>,
> davem@xxxxxxxxx (Dave Martindale) wrote:
>
>> Don Bruder <dakidd@xxxxxxxxx> writes:
>>
>> >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.
>>
>> If you're just going to write out the image again, negative values
>> should be clamped to zero, and values greater than 255 should be clamped
>> to 255 - not wrapped around to zero.
>
> Hmmm... So simple clamping is, despite the counterintuitiveness
> involved, the way to go? Without chasing every possiblity, it seems
> likely to me that would end up with a whole slew of pixels whose
> color-component values are pegged at either 0 or 255, with comparatively
> little "middle ground".
>

No, this is exactly your problem. The negative coefficients in your kernel
can result in negative output pixel values but these are represented as
~255. Rather than a small negative value, implying darker than black, you
get a very bright value.
You apply clipping just after normalization, i.e. to the result for the
whole kernel. It is important to hold your intermediate results sumr etc in
signed int, as you do. Clip the int value to a valid BYTE (unsigned char)
range then build your result color.

The kernel you have here is an edge detection filter. Areas of uniform color
will become black and strong edges will be bright. This doesn't seem to
match your output image so perhaps you are adding the filter result to the
input pixel value. This gives a result that is the original image with the
edges enhanced and this is perhaps your intention. In this case you must add
the signed int filter result to the source pixel and then apply clipping.

When calculating with BYTE values make sure intermediate results are cast to
int.

You could use an averaging kernel - all coefficients = 1 as a test. This
cannot produce negative values and should give you a blurred version of your
input.

Graham



.

Relevant Pages

  • Re: Filtering kernel width
    ... of kernel function becomes irrelevant for 2 pixels, 2x2 pixels, etc. ... Suppose I was using a sinc filter, that has 1 lobe and is 0 outside ... Why should a pixel ... So then basically that's what these filters do: they "blur" the image ...
    (comp.graphics.algorithms)
  • Re: Gaussian Implementation
    ... The first step is to create a kernel. ... you filter the color values. ... The inner-most pixel is called the ... // define 5x5 Gaussian kernel ...
    (comp.graphics.algorithms)
  • Re: Gaussian Implementation
    ...   I am here to get some direction from you guys. ... you filter the color values. ... The inner-most pixel is called the ... A 5*5 kernel leaves 2 rows and 2 columns at all edges unfiltered. ...
    (comp.graphics.algorithms)
  • Gaussian Implementation
    ... The first step is to create a kernel. ... you filter the color values. ... The inner-most pixel is called the ... // define 5x5 Gaussian kernel ...
    (comp.graphics.algorithms)
  • Re: Double hires mode color artifacts
    ... expect of an Apple II, given its resolution and color limitations. ... essentially no change after the window had filled with 14 "dots". ... pixel on host pixel boundaries. ... A filter of 4 bit width in hires should be already sufficent for that. ...
    (comp.sys.apple2)