BMP Color Replacer : Complete Mystery : Algorithm for treating padding doesn't work

**Al3** · 02-11-2015

I am able to consider padding in any other function but that one. That because, I am using a fast way of color replacing, which requires incrementing the index with +3 which causes the inability of treating padding on regular ways. However.. I am almost certain that the conditional algorithm to consider padding, works! Well.. it clearly doesn't, because it causes this:

BMP Color Replacer : Complete Mystery : Algorithm for treating padding doesn't work-compare-png

BMP Color Replacer : Complete Mystery : Algorithm for treating padding doesn't work-compare-png

Code:

union
{
    unsigned long ulColor;
    unsigned char byteColor[4];
} oldColor;
union
{
    unsigned long ulColor;
    unsigned char byteColor[4];
} newColor;

typedef unsigned char               BYTE;
typedef unsigned short int        WORD;
typedef unsigned long int          DWORD;
typedef unsigned longl ong int  DDWORD;

DDWORD
bitfox_color_replace_data
(BYTE *buff, BYTE old_r, BYTE old_g, BYTE old_b, BYTE new_r, BYTE new_g, BYTE new_b)
{
    #define OFFSET_OF_SIZE      0x2
    #define OFFSET_OF_PIXELS    0xA
    #define OFFSET_OF_WIDTH     0x12
    #define OFFSET_OF_HEIGHT    0x16

    DWORD* buffSize     =(DWORD*)&buff[OFFSET_OF_SIZE];
    DWORD* buffPixels   =(DWORD*)&buff[OFFSET_OF_PIXELS];
    DWORD* buffWidth    =(DWORD*)&buff[OFFSET_OF_WIDTH];
    DWORD  buffHeight   =0;

    BYTE pad            =0;

    DDWORD pixels_replaced =0;
    DDWORD i;

    oldColor.byteColor[0]= old_b;  newColor.byteColor[0]= new_b;
    oldColor.byteColor[1]= old_g;  newColor.byteColor[1]= new_g;
    oldColor.byteColor[2]= old_r;  newColor.byteColor[2]= new_r;

    for(i =(*buffPixels); i <(*buffSize); i +=3)
    {
        if( i ==((*buffPixels)+(((*buffWidth)*3)+ pad)*(buffHeight +1)))
        {
            pad =((*buffWidth)%4);
            buffHeight++;
            i += pad;
        }

        if(!memcmp(buff + i, oldColor.byteColor,3))
        {
            memcpy(buff + i, newColor.byteColor,3);

            pixels_replaced++;
        }

    }
    return pixels_replaced;
}

**Salem** · 02-11-2015

Here's a tip.

Start with an algorithm which works, then try to make it efficient.

Starting with something (apparently) efficient, but broken, is the wrong way to go.

If you want it efficient, then remove
- memcmp
- memcpy
- all the references to (*var) which are unaligned memory accesses

Also, DDWORD is massive overkill unless you really are on a 64-bit machine.

**Al3** · 02-11-2015

Originally Posted by Salem

Here's a tip.

Start with an algorithm which works, then try to make it efficient.

Starting with something (apparently) efficient, but broken, is the wrong way to go.

If you want it efficient, then remove
- memcmp
- memcpy
- all the references to (*var) which are unaligned memory accesses

Also, DDWORD is massive overkill unless you really are on a 64-bit machine.

What makes you think I didn't started this function on another way? Firstly the function didn't had memcmp and memcpy.. but then in S/O I got suggested to use it and I realized that it isn't bad to do so.
The direct memory pointing is a fast way and it works. I don't plan to take it away. I am just concerned about the padding.. not the function itself. Am I giving my question incorrectly, because people are getting concerned in everything else but the real problem. This function works if pad == 0.

**Salem** · 02-11-2015

Post something which works, then we can suggest how to make it better.

I've no interest in wading through something broken.

**Al3** · 02-11-2015

Originally Posted by Salem

Post something which works, then we can suggest how to make it better.

Is that Code Review Site? No? This kind of stuff are for http://codereview.stackexchange.com/ not http://cboard.cprogramming.com
Do not try to make a fool out of me, Salem.

Originally Posted by Salem

I've no interest in wading through something broken.

No you are just unable to help. The code provided above works as long as the width of the image buffered is multiple of 4. I was kind to share my code to you, hoping that someone is actually experienced in graphics so to give an idea. at least. If you are not interested in "wading something broken" then you could not post at all, on a first place. But one thing must be clear. I am not looking for tips. This code works and it works faster then the implementations of the people that suggest tips. These are not tips, rather forcing your experience to mine.. and as I see.. your experience with BMP graphics isn't something I could rely on. So no thanks.

**Jimmy** · 02-11-2015

Originally Posted by Al3

Is that Code Review Site? No? This kind of stuff are for Code Review Stack Exchange not http://cboard.cprogramming.com
Do not try to make a fool out of me, Salem.

No you are just unable to help. The code provided above works as long as the width of the image buffered is multiple of 4. I was kind to share my code to you, hoping that someone is actually experienced in graphics so to give an idea. at least. If you are not interested in "wading something broken" then you could not post at all, on a first place. But one thing must be clear. I am not looking for tips. This code works and it works faster then the implementations of the people that suggest tips. These are not tips, rather forcing your experience to mine.. and as I see.. your experience with BMP graphics isn't something I could rely on. So no thanks.

Salem is probably our oldest active regular member. Making a fool of yourself when Salem suggests something is probably a sure fire way to not get any help at all.

**Al3** · 02-11-2015

Originally Posted by Jimmy

Salem is probably our oldest active regular member. Making a fool of yourself when Salem suggests something is probably a sure fire way to not get any help at all.

Okay. Here I am not to compare or to have relationships with members. Tell me why should I care which one was here for a longer time? For me it clearly doesn't matter as he is not able to help. So how old as a member is he.. is something I don't care nor respect. Just like he doesn't care about me. I could be newer here.. but be much more advanced than him. So please, if you are going to protect your respected members, do it on a less-pathetic way. Because "That user" just said he is not interested in helping me.. and I will not fight to receive any help. I've seen people here act like they are desperate. Is it disappointing that I am not?

To be clear once again. I don't respect someone just because he posted to my problem, with something completely irrelevant in my case.
I won't respect him because he is older member too. Simply because I know nothing for him.. I am aware that people don't help mostly because the problem provided above is rather complex. I am licensed programmer though.

**the_jackass** · 02-11-2015

Originally Posted by Al3

"to have relationships with members."

Afaik everyone here is straight. xD

**laserlight** · 02-11-2015

I have deleted several posts in this thread that ended up in a pointless fight. There appeared to be one point of information that may be useful:

Originally Posted by Al3

This function works if pad == 0.

**phantomotap** · 02-11-2015

I have deleted several posts in this thread that ended up in a pointless fight.

O_o

In the process, you also deleted context which may inform other people opinion on whether or not to help the original poster. If you didn't want the fight, you should have locked the thread with such context. The original poster doesn't know where he went wrong going from the claimed traditional implementation to the "fast way" implementation. If he posted that code, we could help the original poster walk through the differences. If the original poster doesn't want to post such code for whatever reasons, the other people at the forum need to know.

Soma

**Al3** · 02-11-2015

Originally Posted by laserlight

I have deleted several posts in this thread that ended up in a pointless fight. There appeared to be one point of information that may be useful:

Thank you. I would ask for that.

**laserlight** · 02-11-2015

phantomotap has a point though. I'm backpedalling to restore this thread and close it. Start another thread if you want, with the additional points about having changed to use memcpy, etc. Since phantomotap is so concerned about "context which may inform other people opinion on whether or not to help the original poster", I'm sure he will be happy to link to this thread from your new thread, hence also providing the valid context. Hopefully we can avoid the bickering there.

Originally Posted by Al3

Is that Code Review Site? No? This kind of stuff are for Code Review Stack Exchange not http://cboard.cprogramming.com

No, code review is part of the scope of this forum community as it is generally about programming in a few programming languages. What is general includes the specific.

Thread: BMP Color Replacer : Complete Mystery : Algorithm for treating padding doesn't work

Thread Tools

Search Thread

Display

BMP Color Replacer : Complete Mystery : Algorithm for treating padding doesn't work

Similar Threads

max heapify and build max_heapify algorithm doesn't work as expected.

integer Count doesn't increment properly, doesn't work with GCC, but does with CC

Why <complete program> doesn't works right?

Packet Filter / Replacer ?

256-Color Bitmap in MFC Resource :: Doesn't Load Right