1. Shrinking bitmaps
Hi Mr Trick,
I'm also interested in your project. My "problem" is this: I use bitBLt
to copy (dutch baseball) signs to a pixmap / window. This works fine. On
larger resolutions however, the signs become to small. I don't want to
design a optimised signs-bitmap for each resolution. So the idea is
this: I design a bitmap for 1280 x 1024. I get the user's resolution and
then convert this bitmap into pixmap optimised for that resolution. In
short: I want to shrink a bitmap.
Bye,
Jasper.
2. Re: Shrinking bitmaps
Hi Jasper.
Until I release my lib with bitmap stuff built in, here is a usefull
function that will shrink or enlarge any sequence that you give it.
Input the array you want resized, and the size that you want it to become,
and it will output a scaled img with the exact dimensions that you
specified.
global function resize_bitmap(sequence img, sequence oSize)
atom iSx, iSy
sequence nImg
iSx = length(img[1])
iSy = length(img)
nImg = repeat(repeat(0,oSize[1]),oSize[2])
for x = 1 to oSize[1] do --for each
for y = 1 to oSize[2] do --pixel
nImg[y][x]=
img[(y-1)*(iSy-1)/(oSize[2]-1)+1][(x-1)*(iSx-1)/(oSize[1]-1)+1]
end for
end for
return nImg
end function
I hope that works fine for you...
=====================================================
.______<-------------------\__
/ _____<--------------------__|===
||_ <-------------------/
\__| Mr Trick
>I'm also interested in your project. My "problem" is this: I use bitBLt
>to copy (dutch baseball) signs to a pixmap / window. This works fine.
> >larger resolutions however, the signs become to small. I don't want to
>design a optimised signs-bitmap for each resolution. So the idea is
>this: I design a bitmap for 1280 x 1024. I get the user's resolution then
>convert this bitmap into pixmap optimised for that resolution. In
>short: I want to shrink a bitmap.
>
>Bye,
>Jasper
3. Re: Shrinking bitmaps
Hi, Jasper,
many moons ago, well before this forum became a YAWN (Yet Another Windows
Nightmare - jiri' tm), I suggested the following simple-minded approach to
scaling of sequences. For the sake of clarity, some rather obvious
optimizations are not implemented (special cases, unrolling of critical
routines, etc), but it is still more than 10 times faster than Mr Trick's
offering, which otherwise seems to work quite well.
jiri
-- scale.ex
-- jiri babor
-- jbabor at paradise.net.nz
-- 3 Feb 2002
function scale(integer m, integer n)
sequence s
integer a, dr, r, j
s = repeat(1, n)
s[n] = m
r = -n+1
dr = 2*(m-1)
a = 2*(n-1)
j = 1
for i = 2 to n-1 do
r += dr
while r >= 0 do
j += 1
r -= a
end while
s[i] = j
end for
return s
end function
function resize(sequence s, integer new_width, integer new_height)
sequence u,v, ri,ro
integer wi,hi
hi = length(s) -- height of input sequence
wi = length(s[1]) -- width of input sequence
u = scale(hi, new_height)
v = scale(wi, new_width)
ro = v
for i = 1 to new_height do
ri = s[u[i]]
for j = 1 to new_width do
ro[j] = ri[v[j]]
end for
u[i] = ro
end for
return u
end function
-- example -----------------------------------------------------------
include image.e
object o
sequence bmp, pal
o = read_bitmap("c:\\windows\\setup.bmp")
if atom(o) then
puts(1, "could not read specified bitmap\n")
abort(1)
end if
pal = o[1]/4
bmp = o[2]
use_vesa(1) -- just in case...
o = graphics_mode(257) -- 640x480x256
all_palette(pal)
display_image({0, 0}, bmp) -- full size
display_image({0, 0}, resize(bmp, 160,120)) -- quarter size, overlayed
while get_key() = -1 do end while -- pause
o = graphics_mode(-1) -- restore original text mode
----- Original Message -----
From: <jaspers_post at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Friday, February 01, 2002 10:59 PM
Subject: Shrinking bitmaps
>
> Hi Mr Trick,
>
> I'm also interested in your project. My "problem" is this: I use bitBLt
> to copy (dutch baseball) signs to a pixmap / window. This works fine. On
> larger resolutions however, the signs become to small. I don't want to
> design a optimised signs-bitmap for each resolution. So the idea is
> this: I design a bitmap for 1280 x 1024. I get the user's resolution and
> then convert this bitmap into pixmap optimised for that resolution. In
> short: I want to shrink a bitmap.
>
> Bye,
>
> Jasper.
4. Re: Shrinking bitmaps
At 07:45 PM 2/3/02 +1300, you wrote:
>
>Hi, Jasper,
>
>many moons ago, well before this forum became a YAWN (Yet Another Windows
>Nightmare - jiri' tm), I suggested the following simple-minded approach to
>scaling of sequences. For the sake of clarity, some rather obvious
>optimizations are not implemented (special cases, unrolling of critical
>routines, etc), but it is still more than 10 times faster than Mr Trick's
>offering, which otherwise seems to work quite well.
>
>jiri
>
Here's mine. For shrinking bitmaps use jiri's offering, if you want to make
them bigger, this routine is considerably faster,and uses a lot less memory too.
graeme
global function resize(sequence bmp,sequence dim)
-- HMI Image Re-Size V2
sequence tx, -- template for x expansion
rx, -- x-expanded bitmap
r, -- return (expanded) bitmap
l -- temp line container
atom d
-- make x template
tx=repeat(0,dim[1])
d=length(bmp[1])/dim[1]
for x=1 to dim[1] do
tx[x]=floor(x*d)+1
end for
tx-=(tx>length(bmp[1]))
-- expand x
l=repeat(0,dim[1])
rx=repeat(l,length(bmp)+1)
for y=1 to length(bmp) do
r=bmp[y]--borrow r as temp ptr
for x=1 to dim[1] do
l[x]=r[tx[x]]
end for
rx[y]=l
end for
rx[length(rx)]=l
-- expand y
r=repeat(rx[1],dim[2])
d=length(bmp)/dim[2]
for y=2 to dim[2] do
r[y]=rx[floor(y*d)+1]
end for
return r
end function
5. Re: Shrinking bitmaps
jiri babor writes:
> many moons ago, well before this forum became a YAWN (Yet Another Windows
> Nightmare - jiri' tm), I suggested the following simple-minded approach to
> scaling of sequences. For the sake of clarity, some rather obvious
> optimizations are not implemented (special cases, unrolling of critical
> routines, etc), but it is still more than 10 times faster than Mr Trick's
> offering, which otherwise seems to work quite well.
I think DirectX/GDI solution should be the fastest, because it can use
graphics cards's hardware to stretch bitmap.
Jasper, you can try this win32libish demo. Try to resize the window !
If you haven't got c:\windows\1stboot.bmp, replace it with another image.
Martin
----------------------
include win32lib.ew
global procedure stretchBlt( atom dst, integer dstX, integer dstY,
atom src, integer srcX, integer srcY,
integer destWide, integer destHigh,
integer srcWide, integer srcHigh,
integer rop )
atom srcDC, dstDC
-- get the DCs
srcDC = getDC( src )
dstDC = getDC( dst )
-- copy area
if not w32Func( xStretchBlt, {
dstDC, dstX, dstY,
destWide, destHigh,
srcDC,
srcX, srcY,
srcWide, srcHigh,
rop} ) then
warnErr( "stretchBlt:StretchBlt failed." )
end if
-- release the DCs
releaseDC( dst )
releaseDC( src )
end procedure
function getBitmapSize( atom handle )
atom struct,mset
atom x,y
mset = new_memset()
-- Allocate a buffer to hold bitmap information
struct = acquire_mem( mset, SIZEOF_BITMAP )
-- load bitmap data into structure
if not w32Func( xGetObject, { handle, SIZEOF_BITMAP, struct} )
then
end if
-- get the values from the bitmap
x = fetch( struct, bmWidth )
y = fetch( struct, bmHeight )
release_mem(mset)
return {x,y}
end function
constant
window1 = create(Window, "StretchBlt test", 0, Default, Default, 200, 200, 0 )
constant bitmap = create(Bitmap, "", window1, 0, 0, 200, 200, 0)
atom hBitmap
hBitmap = loadBitmapFromFile ( "C:\\WINDOWS\\1STBOOT.BMP" ) -- do you have this
one?
procedure drawIt ()
sequence size1, size2
size1 = getCtlSize(window1)
size2 = getBitmapSize(hBitmap)
stretchBlt(window1, 0, 0, hBitmap, 0, 0, size1[1], size1[2],
size2[1], size2[2], SRCCOPY)
end procedure
procedure onOpen_window1 ()
drawIt()
end procedure
onOpen[window1] = routine_id("onOpen_window1")
without warning
procedure onPaint_window1 (int x1, int y1, int x2, int y2)
drawIt()
end procedure
onPaint[window1] = routine_id("onPaint_window1")
procedure onResize_window1 (int style, int x, int y)
repaintWindow(window1)
end procedure
onResize[window1] = routine_id("onResize_window1")
WinMain(window1, Normal)
6. Re: Shrinking bitmaps
Graeme,
I do not want to get into another stupid argument across the Tasman, rugby
and cricket fanatics generate enough of them already, but have done any
tests to support your claims?
I just did a quick speed test expanding a 64x64 bitmap to twice its size,
and my *unoptimized* routine seems to be almost 4 times faster than yours. I
could not compare speeds for shrinking, which was the required
functionality, because your routine, as it is, cannot do it.
I have not attempted any measurements regarding memory usage, but casual
inspection reveals that there should be no significant difference between
the two offerings.
jiri
----- Original Message -----
From: "Graeme" <graemeburke at hotmail.com>
To: "EUforum" <EUforum at topica.com>
Sent: Monday, February 04, 2002 1:49 AM
Subject: Re: Shrinking bitmaps
>
> At 07:45 PM 2/3/02 +1300, you wrote:
> >
> >Hi, Jasper,
> >
> >many moons ago, well before this forum became a YAWN (Yet Another Windows
> >Nightmare - jiri' tm), I suggested the following simple-minded approach
to
> >scaling of sequences. For the sake of clarity, some rather obvious
> >optimizations are not implemented (special cases, unrolling of critical
> >routines, etc), but it is still more than 10 times faster than Mr Trick's
> >offering, which otherwise seems to work quite well.
> >
> >jiri
> >
>
> Here's mine. For shrinking bitmaps use jiri's offering, if you want to
make
> them bigger, this routine is considerably faster,and uses a lot less
memory too.
>
> graeme
>
>
> global function resize(sequence bmp,sequence dim)
> -- HMI Image Re-Size V2
> sequence tx, -- template for x expansion
> rx, -- x-expanded bitmap
> r, -- return (expanded) bitmap
> l -- temp line container
> atom d
>
> -- make x template
> tx=repeat(0,dim[1])
> d=length(bmp[1])/dim[1]
> for x=1 to dim[1] do
> tx[x]=floor(x*d)+1
> end for
> tx-=(tx>length(bmp[1]))
>
> -- expand x
> l=repeat(0,dim[1])
> rx=repeat(l,length(bmp)+1)
> for y=1 to length(bmp) do
> r=bmp[y]--borrow r as temp ptr
> for x=1 to dim[1] do
> l[x]=r[tx[x]]
> end for
> rx[y]=l
> end for
> rx[length(rx)]=l
>
> -- expand y
> r=repeat(rx[1],dim[2])
> d=length(bmp)/dim[2]
> for y=2 to dim[2] do
> r[y]=rx[floor(y*d)+1]
> end for
>
> return r
>
> end function
>
>
>
>
7. Re: Shrinking bitmaps
- Posted by rforno at tutopia.com
Feb 03, 2002
Jiri:
You obviously read some minds, for example mine.
Some of you may have noticed that I seldom post to the list, now. It is
because what Jiri called YAWN. I am an old-style computer geek, and don't
like all Windows' bells and whistles.
Regards.
----- Original Message -----
From: "Jiri Babor" <jbabor at PARADISE.NET.NZ>
To: "EUforum" <EUforum at topica.com>
Subject: Re: Shrinking bitmaps
>
> Hi, Jasper,
>
> many moons ago, well before this forum became a YAWN (Yet Another Windows
> Nightmare - jiri' tm), I suggested the following simple-minded approach to
> scaling of sequences. For the sake of clarity, some rather obvious
> optimizations are not implemented (special cases, unrolling of critical
> routines, etc), but it is still more than 10 times faster than Mr Trick's
> offering, which otherwise seems to work quite well.
>
> jiri
>
> -- scale.ex
> -- jiri babor
> -- jbabor at paradise.net.nz
> -- 3 Feb 2002
>
> function scale(integer m, integer n)
> sequence s
> integer a, dr, r, j
>
> s = repeat(1, n)
> s[n] = m
> r = -n+1
> dr = 2*(m-1)
> a = 2*(n-1)
> j = 1
> for i = 2 to n-1 do
> r += dr
> while r >= 0 do
> j += 1
> r -= a
> end while
> s[i] = j
> end for
> return s
> end function
>
> function resize(sequence s, integer new_width, integer new_height)
> sequence u,v, ri,ro
> integer wi,hi
>
> hi = length(s) -- height of input sequence
> wi = length(s[1]) -- width of input sequence
> u = scale(hi, new_height)
> v = scale(wi, new_width)
> ro = v
> for i = 1 to new_height do
> ri = s[u[i]]
> for j = 1 to new_width do
> ro[j] = ri[v[j]]
> end for
> u[i] = ro
> end for
> return u
> end function
>
> -- example -----------------------------------------------------------
> include image.e
> object o
> sequence bmp, pal
>
> o = read_bitmap("c:\\windows\\setup.bmp")
> if atom(o) then
> puts(1, "could not read specified bitmap\n")
> abort(1)
> end if
> pal = o[1]/4
> bmp = o[2]
>
> use_vesa(1) -- just in case...
> o = graphics_mode(257) -- 640x480x256
> all_palette(pal)
> display_image({0, 0}, bmp) -- full size
> display_image({0, 0}, resize(bmp, 160,120)) -- quarter size, overlayed
> while get_key() = -1 do end while -- pause
> o = graphics_mode(-1) -- restore original text mode
>
>
> ----- Original Message -----
> From: <jaspers_post at hotmail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Friday, February 01, 2002 10:59 PM
> Subject: Shrinking bitmaps
>
>
> > Hi Mr Trick,
> >
> > I'm also interested in your project. My "problem" is this: I use bitBLt
> > to copy (dutch baseball) signs to a pixmap / window. This works fine. On
> > larger resolutions however, the signs become to small. I don't want to
> > design a optimised signs-bitmap for each resolution. So the idea is
> > this: I design a bitmap for 1280 x 1024. I get the user's resolution and
> > then convert this bitmap into pixmap optimised for that resolution. In
> > short: I want to shrink a bitmap.
> >
> > Bye,
> >
> > Jasper.
<snip>
>
>
>
8. Re: Shrinking bitmaps
At 04:25 AM 2/4/02 +1300, you wrote:
>
>Graeme,
>
>I do not want to get into another stupid argument across the Tasman, rugby
>and cricket fanatics generate enough of them already, but have done any
>tests to support your claims?
Umm... yes.
I used the test demo you posted a few days ago that uses the 640x480 windows
setup bitmap.
i put each resize routine in a 200 iter loop. first i got them to do 660x660,
then 1280x960. Both times my routine was twice as fast. Then i tried 6400x4800
Your routine caused an out of memory error. Mine worked fine
>
>I just did a quick speed test expanding a 64x64 bitmap to twice its size,
>and my *unoptimized* routine seems to be almost 4 times faster than yours.
Was it? I'll remember that next time I'm resizing a postage stamp.
>I have not attempted any measurements regarding memory usage, but casual
>inspection reveals that there should be no significant difference between
>the two offerings.
The thing that has escaped your casual inspection is the way the return
bitmap is built. Your routine uses a sequence the size of the target bitmap.
My routine expands the bitmap in the x-axis, then builds the return sequence
by making multiple pointers to the first level elements of the x-expanded
bitmap. This is why my routine is faster and uses less memory.
Pity bout the cricket though ...... :(
>
>jiri
>
graeme
9. Re: Shrinking bitmaps
Graeme is good at sarcasm:
>>I just did a quick speed test expanding a 64x64 bitmap to twice its size,
> >and my *unoptimized* routine seems to be almost 4 times faster than
yours.
>
> Was it? I'll remember that next time I'm resizing a postage stamp.
Innocently I thought a 128x128 bitmap was a more practical example than
6400x4800, roughly the size of Australian ego.
This time Graeme is in really good form:
> The thing that has escaped your casual inspection is the way the return
> bitmap is built. Your routine uses a sequence the size of the target
bitmap.
In line 7 of my resize function the return sequence is clearly initialized
as a column just one integer wide. It does not take exceptional analytical
skills to see that. Or does it?
Enough.
jiri
10. Re: Shrinking bitmaps
Now now, jiri! Play nice! You may be a clever (some may say brilliant) coder
(others may say hacker), but don't be a meanie-head! You want to set a good
example for the youth... :)
> Graeme is good at sarcasm:
>
> >>I just did a quick speed test expanding a 64x64 bitmap to twice its
size,
> > >and my *unoptimized* routine seems to be almost 4 times faster than
> yours.
> >
> > Was it? I'll remember that next time I'm resizing a postage stamp.
>
> Innocently I thought a 128x128 bitmap was a more practical example than
> 6400x4800, roughly the size of Australian ego.
>
>
> This time Graeme is in really good form:
>
> > The thing that has escaped your casual inspection is the way the return
> > bitmap is built. Your routine uses a sequence the size of the target
> bitmap.
>
> In line 7 of my resize function the return sequence is clearly initialized
> as a column just one integer wide. It does not take exceptional
analytical
> skills to see that. Or does it?
>
> Enough.
>
> jiri
11. Re: Shrinking bitmaps
On Sun, 3 Feb 2002 21:21:59 -0600, you wrote:
>
>> Jiri:
>> You obviously read some minds, for example mine.
>> Some of you may have noticed that I seldom post to the list, now. It is
>> because what Jiri called YAWN. I am an old-style computer geek, and don't
>> like all Windows' bells and whistles.
>
>If you want to create programs people will use, you better get used to it.
I would love to write programs:
DOS = text/minimal - rock solid
Windows = largest installed user base, therefore max features
(holding the middle ground in stability terms)
Linux = cutting edge - allowed to be a bit flakey
(with a text/rock solid version an option)
But until I find a suitable API set (if it needs source level tools to
build three/four versions so be it, but it must be automated) I feel
obliged to stick with windows.
Ideally (naively?) it would just be a different set of include files
with null routines for unsupported features on each platform?
Pete
12. Re: Shrinking bitmaps
On Friday 08 February 2002 06:49 pm, petelomax at blueyonder.co.uk wrote:
> I would love to write programs:
> DOS = text/minimal - rock solid
> Windows = largest installed user base, therefore max features
> (holding the middle ground in stability terms)
> Linux = cutting edge - allowed to be a bit flakey
> (with a text/rock solid version an option)
>
> But until I find a suitable API set (if it needs source level tools to
> build three/four versions so be it, but it must be automated) I feel
> obliged to stick with windows.
>
> Ideally (naively?) it would just be a different set of include files
> with null routines for unsupported features on each platform?
Such a thing would be nice, except for the fact that for each of the
platforms, there's something that it cannot do which the others can.
So, a program written to run on ALL, would have to be written to the
lowest common denominator. The result would be programs which
look old-fashioned and somewhat amateurish. And probably lack
features which would make them competitive in the marketplace.
Regards,
Irv
