ahhh maybe that's it.

You should have used a relative path I guess. ;)
Posted on 2002-03-19 19:31:04 by iblis
Yep, I could have used GetModuleFileName to find the correct directory, assuming the end user didn't move good ole Homer, strip off the exeacutable name, tack on Homer's file name...

I thought it best (since it was just a test app) to give explicit directions WHERE to put it, where the path was hard coded (to change either the pic or the path), and let the user play.


Gee guys, RTFM still applies. ;-)



Jimmy: I'm happy it worked so well for you. Shrinking the filesize is what I wanted to accomplish. Looks like you scored an 88% reduction.
Posted on 2002-03-19 22:55:51 by Ernie
Ernie, why not just use a relative path? So much easier for everybody.
Hardcoded paths = lame.
Posted on 2002-03-19 23:03:23 by f0dder

Woohoo

Just wanted to drop a line saying that after some minor changes (had to change 1 line of code) the image.lib did it's wonder already.. The Filesize got reduced from 3.8MB to an amazing 444KB.. Small is beautiful ;)

I'm never working with bmp's again.. (lol)

PS: It works like a charm on XP.


I was in an equivalent situation some months ago...
I had to code an autorun and I wanted it to be small !
But the Bitmap was way too big and I didn't want to use the Delphi/VB mess or use an exe packer on a 1 mb large executable.
As my original pic was in jpeg, i had to convert it in bmp first and the pic was way bigger than the jpeg, for sure...
Ernies method is definitely the solution !

I remember when I coded in VB (don't mock me please :rolleyes: ), it had native support for, bmp. gif, jpeg and wmf files...
I assume it is via the same COM method right ?
Can somebody confirm this theory please ?
Thanks.
Posted on 2002-03-20 02:01:42 by JCP
imo it's a lot easier to keep your files in the same directory as the exe, then you don't need a path.
OpenSomeFile( "myFile.txt" );
will open just fine if it's in the same dir. much easier for testing purposes.


Granted I should have "RTFM" but admitedly I skimmed over your first post. Bad habit. Had I read it I probably wouldn't have put it in MASM32 dir anyhow, as I like to keep things nice and orderly in there. That would be like asking me to unzip your files into c:\windows. There's enough crap in there already ;)
Posted on 2002-03-20 07:29:15 by iblis
Okay, I'm trying Ernie's library for the first time, and I've run into a few problems.

First, on some images, BitmapFromFile returns 00h, even when called with a path that I know is valid.

When I do get a bitmap handle back, calling GetBitmapDimensionEx on that handle returns dimensions of 0 x 0.

(EDIT: I "adjusted" the library to store the pixel dimensions of the image, with SetBitmapDimensionEx. That fixed problem 2, but I still get ERROR_FILE_NOT_FOUND on about every other file I try to load.)
invoke	SetBitmapDimensionEx, tempBitmap, dwWidth, dwHeight, NULL

All of the images I'm trying to load worked fine when I called COM directly.
Posted on 2002-03-20 16:29:43 by The Worrier King
Ernie, why not just use a relative path? So much easier for everybody. Hardcoded paths = lame.



Gee, sorry fodder. Perhaps you should try a beginners forum if these concepts are beyond your understanding.
Posted on 2002-03-20 19:40:00 by Ernie
The Worrier King,

Yikes, what happened? OK, here's what I can think of offhand:

1) Your OS version doesn't support something I use (unlikely as you get it to work doing it manually)

2) Somehow your path or file name or file extrnsion is incorrect. Note this routine used OleLoadPicturePath, which required the pathname (fully qualified path and file name) to open the file.

3) something else....


In the something else catagory, please try this is you would. Stick these two lines into BitmapFromFile.ASM and recompile:

MessageBoxW PROTO :DWORD, :DWORD, :DWORD, :DWORD

invoke MessageBoxW, 0, pwszFileName, 0, 0


Put the 2nd statement just before OleLoadPicturePath. MessageBoxW is one of the very few Unicode supported API's that is valid in all Windows flavors, so it will display the pathname used by OleLoadPicturePath.


Please let me know if something significant shows up (engineering speak for a real bug of mine). Also, you say this occures on 'some' images, I would appreciate a copy of any image that is not properly loaded. Email works for that.
Posted on 2002-03-20 19:53:46 by Ernie

Worrier King,

Yikes, what happened? OK, here's what I can think of offhand:

3) something else....

In the something else catagory, please try this is Please let me know if something significant shows up (engineering speak for a real bug of mine).
FOUND IT!!!! I think I sent you this before, in a thread in the COM forum.

MultiByteToWideChar exhibits anti-social behavior when the destination buffer is exactly 2* the source buffer. I guess it needs a couple extra bytes scratch space. If you size the buffer the way you had it, the Unicode string may wind up with an extra bogus character at the end, causing the load to fail.

If you change the beginning of BitmapFromFile to...
LOCAL wszFileName[MAX_PATH]:WORD, dwLength:DWORD, pPicture:DWORD, hNewBmp:DWORD


invoke CoInitialize, NULL
mov pPicture, NULL ; NULL pointer for later use

; first, we need the filename in Unicode
invoke MultiByteToWideChar, CP_ACP, 0, pszFileName, -1, ADDR wszFileName, MAX_PATH
; now we can create out picture object
invoke OleLoadPicturePath, ADDR wszFileName, NULL, NULL, NULL, ADDR IID_IPicture, ADDR pPicture
...all becomes right with the world.:alright:
Posted on 2002-03-20 20:42:50 by The Worrier King
Worrier,

Thanks, good report.

Gee, and I even go thru the trouble of defining the buffer size as 2X + 2, where X is the ASCII character count. And that takes a
lstrlen call to boot.

Now I wonder what happens if we pass in a string that's already MAX_PATH. Shoud we leave just 2*MAX_PATH for unicode? Or 2*MAX_PATH+2? +4?

How about we just go for 3*MAX_PATH and be done with it.

Seriously... Using a fixed string length is A) acceptable, since paths do have the MAX_PATH limitation, and are B) quicker to define as we don't have to search for the length.

OK, so say we define the buffer as twice MAX_PATH (or twice 260 for 520). Should we add a few bytes anyway? I'd be temped to add them 'just in any case' to be safe and sure.

The other alternative is to use MultiByteToWideChar to compute the length of the unicode string IT wants, by passing it a zero as the last parameter (receive buffer size).

Since I'm a tightwad in allocating memory, I'm going to try this last way.

I reposted the code with this change. The sample paint.exe now looks for:


szFile BYTE "C:\masm32\Image\long long long long long "
BYTE "long long long long long long long long long "
BYTE "long long long long long long long long long "
BYTE "long long long long long long long long long "
BYTE "long long long long long long long long long "
BYTE "long long long long long name.bmp", 0


This seems to be a MAX_PATH filename, it loads sucessfully for me.
Posted on 2002-03-20 22:07:12 by Ernie
============
Gee, sorry fodder. Perhaps you should try a beginners forum if these concepts are beyond your understanding.
============

:grin:

Regards,

hutch@movsd.com
Posted on 2002-03-20 23:02:04 by hutch--
why i cannot create a lib file that only contains one function that is BitmapFromFile ( i know i still lack of knowledge about com).

There is an error when i linked it. Are those functions have a close relationship so we cannot make it independently or i am wrong when i made a lib file.

for example i i want to create image.lib with command

ml /c /coff BitmapFromFile.asm

lib /out:image.lib *.obj

image.lib was created, but there was an error in linking

i know the key is about com knowledge and my bailiwich is not reach there.
Posted on 2002-03-21 06:34:19 by newbies

Gee, sorry fodder. Perhaps you should try a beginners forum if these concepts are beyond your understanding.

That comment was about as lame as using hardcoded paths. Unless,
of course, the COM method is lame and doesn't support relative paths.
Posted on 2002-03-21 14:18:45 by f0dder
Not only does it support relative paths, but it supports URLs ;)
Posted on 2002-03-21 14:27:54 by iblis
Very goo library ernie.


I found a bug - not exactly on the code uou made, but ...here goes.


I coded a small app with imagelib and put jpg on a window that is able to resize proportionally (i posted on the board)...

When you resize the window the centered image (originally it was a bitmap), was resizing proportionally. I change the image for a jpg...and the api call (was invoke LoadBitmap).

What is happenign is due to teh compression of the jpg the image that is resizing is strongly ugly (deformed)....

I remember on this board that butch77 coded a routine able to resize images correctly (http://www.asmcommunity.net/board/index.php?topic=1513&highlight=resize).

Maybe the same routine coding can be applyed to your library in order to the image (jpg, bmp, gif or anyother), can be able to be resized based on their inner pixels.

Regards

Beyond2000!
Posted on 2002-03-26 13:41:40 by Beyond2000!
When an image is saved in a file, certain information about that image is also stored inside the file, so that the intrinsic width and height of the image is preserved.

The image lib I made takes advantage of these values and returns a bitmap representation that pixel for pixel matches this intrinsic stored width and height. Thus it contains all the information saved in whatever format the picture was in.

Any finite image, when zoomed to sufficient size will 'pixelate,' or turn to a mass of large color blobs. The information just isn't there anymore.

Sure, you may have seen computers in the movies add this detail back in, but thats a movie. I'd personally like a James Bond flying back pack, but it just ain't possible. ;-)
Posted on 2002-03-26 19:36:48 by Ernie
No, ernie....


I meant that due to the jpg compression the image is heavelly pixelated (scrambled)...using a bitmap it works just fine.

Your code is awsome, all i try to say is that if use another code routines like dibresize (on the board) has...it can be applyed to jpg or gif, and make the pixelation quite good as if you use an bitmap.

The pixelation of an jpf nto only is caused when you enlarge it, but when it is reduce too...

The code that butch77 uses, seems to be applyed to jpg, gif, pic and bmp.


I on;ly saying thjat if you implement your code with the same routines, it would be a better version then it is already.

You said that it was an alpha version, i'm just trying to help to improve your library.

I'll try to use the butch77's routine and see if it can be applyed to your lib, and send it here to you analyse.

It could be interesting.

Regards,

Beyond2000!
Posted on 2002-03-26 23:10:55 by Beyond2000!
The file was made in VB, (Not the dll that has the resize function), trying to convert the main VB executable to asm, can get more clues on resizing the mage without too many lost of data /quality.


here it is
Posted on 2002-03-26 23:50:45 by Beyond2000!
When you 'open' a picture file with this image library, you get back a handle to a bitmap.

It is no longer a gif, jpg, wmf, icon, or whatever it started as.

It is now a bitmap.

Any methods you have in handeling bitmaps (such as butch77's code) may be used to manipulate these images.

As far as adding a resize method to this lib, that falls outside the scope of the project. The goal is to open image files in many formats.

It seems to do that quite nicely. I'll call it a day.
Posted on 2002-03-27 22:24:05 by Ernie

Is paint.exe supposed to do something?
It opens a blank window, and I don't see a picture. But in the paint.asm file I see it calls your loadpicture routines in the WM_CREATE.
This is on Win XP.


the same thing happens on my w2k box.
i unziped the image folder into my masm32 folder, is this correct?
Posted on 2003-02-27 22:03:17 by Homer