Has anyone used gdiplus to change hue?

[NoCforMe]

@Zedd: try the attached new version. Handles 24bpp images correctly (like almost all JPGs). Code's a little more complicated, but not too much.

[guga]

Tks guys. Good to know these diferences.

NoCForme, about

Symbolic constants:
name EQU value

Data declarations:
name, optional  DB/DW/DD/DQ value(s)

Yeah, i remember simlar of those in RosAsm when activating the Preparse Alternates. I never used, though.

Is these syntax more similar to Masm ? Those are the ones the current version of rosAsm can assemble:


mov  ecx  D[Counter]
mov  ecx  dWord [Counter]
mov  ecx  dWord Ptr [Counter]

mov  ecx  [Counter]
mov  ax  [Counter]
mov  [Counter]  bl

; Seems the same as your examples.
[TRUE  =  1,    FALSE  =  0]
[TRUE  EQU  1,    FALSE  EQU  0]

Also syntax with things like
Byte Ptr[Value]
Dword Ptr[Value]
Qword Ptr[Value]
etc are also allowed

What i never saw was the Struct token, but this can be implemented if needed. On this way, it would also be easier to create a sort of translator later.

I never used the alternates preparser so far. I personally don´t like it, but it may be needed by someone in the future, so once i succeed to finish the major updates i´ll try to focus on those alternatives syntaxes. Of course, i don´t plan to make RosAsm assemble all masm syntax (i.e.: all of the fixed tokens), specially because we don´t use things like directives, assume, .data, .code etc, but i guess it won´t hurt adding additional alternatives syntaxes a bit more compatible to masm. I´ll put those information you and Zedd did on the development area on the source, so i won´t forget about it on the future.

[NoCforMe]

Is these syntax more similar to Masm ?

mov  ecx  D[Counter]
mov  ecx  dWord [Counter]
mov  ecx  dWord Ptr [Counter]

You need a comma there:

Code Select Expand

mov  ecx, CounterNo "D[  ]" weirdness, either.

; Seems the same as your examples.
[TRUE  =  1,    FALSE  =  0]
[TRUE  EQU  1,    FALSE  EQU  0]

Again, lose the square brackets, but yes:
you can use either the equal sign or EQU, although they have slightly different meanings (an EQU cannot be changed later)

Also syntax with things like
Byte Ptr[Value]
Dword Ptr[Value]
Qword Ptr[Value]
etc are also allowed

Yes; those are modifiers, like

Code Select Expand

  MOV  ByteSizeVar, BYTE PTR [EDX]
  MOV  AL, BYTE PTR DwordSizeVar
Note no square brackets around that last one.

[zedd151]

@Zedd: try the attached new version. Handles 24bpp images correctly (like almost all JPGs). Code's a little more complicated, but not too much.

result


source jpg image
You cannot view this attachment.

It works fine for 24 bit bitmaps though.

[NoCforMe]

Ack.
Could you post that image file so I can check it out?
I think I might know what the problem is. Was just thinking about it.
When processing bitmap images, you have to take into account this thing called stride, which is the distance between scan lines.
That's because some bitmaps have padding, since a scan line must begin on a DWORD boundary.
So depending on the bitmap size, lines may have padding.
I'm just going through the bitmap as if it's just a big linear array.
Wrong. The correct way to process a bitmap is line by line, treating it as a 2D array.
Just means you need an inner and an outer loop, where you move [stride] bytes from one line to the next.

[zedd151]

Ack.
Could you post that image file so I can check it out?

it is in above post. That file was saved with photoshop. right click and save image as...
For jpgs saved with mspaint, it works fine. 

[guga]

Is these syntax more similar to Masm ?

mov  ecx  D[Counter]
mov  ecx  dWord [Counter]
mov  ecx  dWord Ptr [Counter]

You need a comma there:

Code Select Expand

mov  ecx, CounterNo "D[  ]" weirdness, either.

; Seems the same as your examples.
[TRUE  =  1,    FALSE  =  0]
[TRUE  EQU  1,    FALSE  EQU  0]

Again, lose the square brackets, but yes:
you can use either the equal sign or EQU, although they have slightly different meanings (an EQU cannot be changed later)

Also syntax with things like
Byte Ptr[Value]
Dword Ptr[Value]
Qword Ptr[Value]
etc are also allowed

Yes; those are modifiers, like

Code Select Expand

  MOV  ByteSizeVar, BYTE PTR [EDX]


Oh, the commas are mandatory in masm then. Ok, the current version of RosAsm can also handle those commas (but they are not fixed, is optional to use - the internal parsers will simply skip those). But, currently, those can also be assembled as:

MOV  ByteSizeVar, BYTE PTR [EDX].

About removing the squared brackets, i´ll need a way to implement this. Or simply leave this to the translator. Currently, the brackets are made to distinguish the several different statements (Variables, equates, macros)

[TRUE  =  1,    FALSE  =  0]
[TRUE  EQU  1,    FALSE  EQU  0]

Can be written one on each bracket

[TRUE  =  1]
[FALSE  =  0]
[TRUE  EQU  1]
[FALSE  EQU  0]


But, on masm then we should use no brackets at all ? Just this ?

TRUE  =  1
FALSE  =  0
TRUE  EQU  1
FALSE  EQU  0

But., how the assembler will distinguish if they are data, equates, variables or code ? Or the absence of brackets in masm only works for equates ?

[NoCforMe]

But, on masm then we should use no brackets at all ? Just this ?

TRUE  =  1
FALSE  =  0
TRUE  EQU  1
FALSE  EQU  0

Yep, that's it.

But., how the assembler will distinguish if they are data, equates, variables or code ? Or the absence of brackets in masm only works for equates ?

They're neither code nor data, just symbolic constants, meaning they evaluate to a numeric value and can be used in place of numbers in statements.

The EQU operator does, however, have other uses: for example,

Code Select Expand

$CRLF            EQU <13, 10>

results in a sequence of two bytes if used in a DB statement, like so:

Code Select Expand

Message  DB "Halt! Who goes there?", $CRLF, 0

Then there are text macros. Let's don't even go there yet ...

I guess you could say that EQU and friends are all part of the preprocessor, like in C.

[guga]

Ok, tks, David    

I inserted the information you guys provided to the development part of the source.

[zedd151]

Hi guga, could you start a new topic for your rosasm to masm translation issues? When you were posting about it here, it kind of interrupted the flow of the conversation underway between NoCforMe and myself.

I am not asking that any posts be removed from here or deleted, but if you want to continue with your rosasm to masm syntax discussions I am asking very politley to please start a new topic and do not continue here, please. 

[zedd151]

@Zedd: try the attached new version. Handles 24bpp images correctly (like almost all JPGs). Code's a little more complicated, but not too much.

Now back to the topic.

NoCforMe...

Why do you only have 3 choices to change hue. I think there should be six.

Red to Blue
Blue to Red

Red to Green
Green to Red

Blue to Green
Green to Blue

Also:
What I would (and might) do is use the same static to display the results and the source image.
Any changes the would be applied to the already processed image, after initially processing the source image.

If your methods are sound, changing from red to blue and back again, the result should match the source image or have the perception of being the same.

Anyway, these were some things I was thinking about. I don't have a lot of time for coding the next few days (6 acre property, only half finished with yard work), but when I do, I will explore doing what I had mentioned above.

[NoCforMe]

@Zedd: try the attached new version. Handles 24bpp images correctly (like almost all JPGs). Code's a little more complicated, but not too much.

Now back to the topic.

NoCforMe...

Why do you only have 3 choices to change hue. I think there should be six.

Red to Blue
Blue to Red

No.
They're swaps; red<-->blue interchanges the two, so only 1 choice needed there.

There are, of course, lots of other ways you could mess with a bitmap.

If you do play with that testbed program, be sure to implement those inner and outer loops I mentioned earlier so you're processing the bitmap line-by-line. Otherwise, knock yourself out.
Just be sure to post any interesting results here.

[zedd151]

Just be sure to post any interesting results here.

Absolutely! Even if they are not very interesting.

They're swaps; red<-->blue interchanges the two, so only 1 choice needed there.

I did not realize that, clicking the button again did nothing so I figured it was only a one way color shift. I have mainly been testing with images/bitmaps with only a few colors. I will look at it in more detail with many more colors in the same image to see for myself.

[zedd151]

I did a quick test by using a blue image and clicking red<--->blue. Indeed it turned red.    I missed that "<--->" meant bidirectional. 

[NoCforMe]

Well, now maybe you can come up with your own wicked way of changing bitmap pixels around ...
I'm all out of ideas ATM.