News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests
NB: Posting URL's See here: Posted URL Change

Main Menu

My first program in MASM32

Started by iZ!, February 22, 2015, 09:46:17 PM

Previous topic - Next topic

dedndave

in case you weren't aware, UINT is an unsigned DWORD integer

there are a few advantages to using structured data
first, it is easier to read and understand, later (after you've forgotton how it works - lol)
second, you can load a register with the base address of the structure, then access the other members by name
finally, if you move data around, you don't risk accidently splitting up what must be a single ordered group of data items
nonetheless, you don't have to use structures
i've written many programs without them (where i should have used them)

your program should be a very simple one, because all images are 640x480 and only 16 colors are used

for the 24-bit image, the header should look like this
; bmfh            BITMAPFILEHEADER <>
;   bfType          dw ? ;= 'BM'
;   bfSize          dd ? ;total file size = 921654
;   bfReserved1     dw ? ;= 0
;   bfReserved2     dw ? ;= 0
;   bfOffBits       dd ? ;BMPFILEHDR structure size = 54
; bmih            BITMAPINFOHEADER <>
;   biSize          dd ? ;BITMAPINFOHEADER structure size = 40
;   biWidth         dd ? ;image width in pixels = 640
;   biHeight        dd ? ;signed image height in pixels = 480
;   biPlanes        dw ? ;= 1
;   biBitCount      dw ? ;= 24
;   biCompression   dd ? ;= BI_RGB = 0
;   biSizeImage     dd ? ;image data bytes = 921600
;   biXPelsPerMeter dd ? ;= 0
;   biYPelsPerMeter dd ? ;= 0
;   biClrUsed       dd ? ;= 0
;   biClrImportant  dd ? ;= 0

for 24-bit images, there is no palette or bit masks, so the image data follows the header

for 16-color images, the header should look like this
; bmfh            BITMAPFILEHEADER <>
;   bfType          dw ? ;= 'BM'
;   bfSize          dd ? ;total file size = 153718
;   bfReserved1     dw ? ;= 0
;   bfReserved2     dw ? ;= 0
;   bfOffBits       dd ? ;BMPFILEHDR structure size = 118
; bmih            BITMAPINFOHEADER <>
;   biSize          dd ? ;BITMAPINFOHEADER structure size = 40
;   biWidth         dd ? ;image width in pixels = 640
;   biHeight        dd ? ;signed image height in pixels = 480
;   biPlanes        dw ? ;= 1
;   biBitCount      dw ? ;= 4
;   biCompression   dd ? ;= BI_RGB = 0
;   biSizeImage     dd ? ;image data bytes = 153600
;   biXPelsPerMeter dd ? ;= 0
;   biYPelsPerMeter dd ? ;= 0
;   biClrUsed       dd ? ;= 0
;   biClrImportant  dd ? ;= 0

for 16-color images, there are 16 RGBQUAD's, followed by the image data

notice that, besides the palette, only 4 other values are different between the 2 file types

EDIT: one other little note....
the 4th byte of the RGBQUAD's must be 0
many programs won't properly read a BMP file if they are anything else   :icon_rolleyes:

iZ!

Correction to the code of my prog. : free hMem  -> invoke GlobalFree hMem
                                                     free hMem2  -> invoke GlobalFree hMem2

         

iZ!

Ok I corrected the code and, for those interested how it works, I added some comments and replaced variable names so it's understandable for an English speaking coder. Feel free to ask me for explanation if needed.

iZ!

Dave: Thanks for informing me about the padding issue.

iZ!

I updated the code.. I added the handler for over 16 colors images.

FORTRANS

Hi Dave,

Quote from: FORTRANS on February 24, 2015, 01:37:56 AM
   I will have to read up on that algorithm that scolorq uses.
It might suggest improvements in my program.

Quote from: dedndave on February 24, 2015, 02:57:38 AM
hi Steve
i tried to understand his code - no luck - lol
you are more familiar with C than i am

   A first look at the paper shows that it is mostly opaque.  I
recognize some of the methods, and can infer some of the
others, but it will need more than one reading to provide anything
useful.  The pairwise clustering algorithm I am using is much less
complicated in my opinion, and may provide better results.  (That
depends on the criteria used to define "better".)  And Floyd-
Steinberg dithering seems a lot simpler than whatever they are
using at first glance, though they claim better performance.

   The use of a different color space than RGB may require some
exploration.  I was trying to do some work on that for other
reasons.  So,... maybe.  A reread may show something else of
interest, if it doesn't make my brain hurt.

   I didn't see any C code.  As my forum name implies, that may
not have helped all that much anyway.  Few people try to create
understandable code, in any language, in any event.

Regards,

Steve N.

dedndave

it's only difficult for conversion to 16-color images
if you have 256 colors, there's a lot you can do just using a well-chosen standardized palette
one of my "back burner" projects involves designing my version of "the ultimate" 256-color palette   :biggrin:
my current thinking is to use 248 of the colors, then leave 8 unassigned for customization

iZ!

The code had a bug for a while. I updated both, the code and the EXE.

FORTRANS

Hi Dave,

Quote from: dedndave on February 26, 2015, 06:17:45 AM
it's only difficult for conversion to 16-color images
if you have 256 colors, there's a lot you can do just using a well-chosen standardized palette
one of my "back burner" projects involves designing my version of "the ultimate" 256-color palette   :biggrin:
my current thinking is to use 248 of the colors, then leave 8 unassigned for customization

   Well, If you use the 16 "Standard Windows" and six shades of RGB
channels for 216 colors covering the full gamut to avoid missing colors,
or the dithering problems when your error term exceeds the available
colors, you get 232 colors (and a run on sentence).  that gives 24
colors left over for customization.  Depending on what you can do
with the 24 colors, this gives a sort of minimum quality image.

   Now a days for a 256 color palette, I reduce to 248 colors best
fit to the image, and add the 8 colors for the corners of the color
cube.  That gives a good image and avoids most dithering problems.
At first glance, it would appear that it should avoid all of the dithering
problems, which explains the debugging comment above.

   Depending on your method of palette generation and dithering
algorithm, you could start with the 16 standard colors and a color
cube of 64 colors.  That leaves 176 custom palette colors, which
should give a pretty good image.  Actually, as the 16 and 64 colors
mentioned overlap, you can get another 8 custom colors to play
with.

Cheers,

Steve N.

dedndave

hi Steve
the 6x6x6 color cube is part of what i have in mind
i want to linearize it, though
what that lacks is gray shades
so, you add some grays, and some of the EGA/CGA "standard colors" that the cube doesn't handle, as you mentioned
i was just playing with the linearization algo   :P

in the past, i have converted a few 24-bit images using a similar palette
the results were surprisingly good

FORTRANS

Hi Dave,

Quote from: dedndave on February 27, 2015, 01:53:54 AM
the 6x6x6 color cube is part of what i have in mind
i want to linearize it, though

   If you mean doing a gamma corrected set of linear steps, then
I think that is a good idea.  I have been playing around with some
image processing, and gamma correction makes things work a
lot better.  A bit tedious though.

Cheers,

Steve N.

dedndave

right - real color space is no where near a cube - lol

in fact, more could be done, beyond simple gamma correction
but, it should help

in real color space, you can see how selecting a color to represent many might evolve
the image below shows what an optimal selection of 25 colors might look like



i don't really agree with that selection
too many greens and reds
not enough yellows, blues, cyans, and violets
and no grays

dedndave

here's a palette i was working with about 12 years ago
it worked pretty well, but you can see the non-linear gamma
the effect that shows in the grays also shows in reds, greens, and blues - just not displayed that way
we could also add a few colors to better display sepia-tones

Gunther

Hi Dave,

Quote from: dedndave on February 27, 2015, 05:23:36 AM
here's a palette i was working with about 12 years ago
it worked pretty well, but you can see the non-linear gamma
the effect that shows in the grays also shows in reds, greens, and blues - just not displayed that way
we could also add a few colors to better display sepia-tones

interesting idea, indeed. That table could be used for a large range of standard images. But it must be clear that we've some kind of pathological pictures for which the color table will fail.

Gunther
You have to know the facts before you can distort them.

dedndave

certainly, there are some images that won't convert well using that palette
but, my guess is they don't need to be 16, 24, or 32-bit images
probably already 256 color

i don't know how "pathological" they are   :biggrin:

you can take that palette, and display a picture with a lake, sky, grass, flowers, a face, etc
you'll be amazed how well it turns out