|
|
Well, ehm, I'll try to express my problem in english...
I'm using aarot to rotate a vehiclepointer in a program monitoring position and line of sight of an autonomous underwater vehicle.
The degree-values are changing continously.
So, I got no output-image as presented in the demo-project. Theres no new window for each rotated image, that could be closed. I just attach the rotated image...
...like this:
HBITMAP hsrcbmp = (HBITMAP)LoadImage(NULL, szFilename, IMAGE_BITMAP, 0, 0, LR_DEFAULTSIZE | LR_LOADFROMFILE);
CBitmap bmp;
HBITMAP dstbmp = aarot::rotate(hsrcbmp, -m_dHeadingFromAUV, NULL, 0xFFFFFF, false);
bmp.Attach(dstbmp);
The problem is, that the program uses more and more memory until it finally crashes. The used memory increases in steps of 4K.
Does anyone see a way to free the used memory each time a new rotated image was displayed?
Unfortunately I'm not that much into c++-programming. So I hope there's a very simple answer to my problem.
Greetz & Thanks
mephistho
|
|
|
|
|
Ok, I'll take a look for a memory leak
-- modified at 16:48 Tuesday 7th March, 2006
Are you destroying the bitmaps you create with Aarot? I managed to find one memory leak, but it only occurs if the transform is canceled and it is only a couple bytes.
|
|
|
|
|
Well, what would "destroying" look like?
This is everything I do with aarot:
void CControlPanelDlg::PaintVehiclePointer(int x, int y)
{
CString szFilename("res\\arrow_white.bmp");
HBITMAP hsrcbmp = (HBITMAP)LoadImage(NULL, szFilename, IMAGE_BITMAP, 0, 0, LR_DEFAULTSIZE | LR_LOADFROMFILE);
CBitmap bmp;
HBITMAP dstbmp = aarot::rotate(hsrcbmp, -m_dHeadingFromAUV, NULL, 0xFFFFFF, false);
bmp.Attach(dstbmp);
//bmp.Attach(hsrcbmp);
CClientDC dc(this);
CDC bmDC;
bmDC.CreateCompatibleDC(&dc);
CBitmap *pOldbmp = bmDC.SelectObject(&bmp);
BITMAP bi;
bmp.GetBitmap(&bi);
dc.BitBlt(x,y,bi.bmWidth,bi.bmHeight,&bmDC,0,0,MERGEPAINT);
m_oldX = x;
m_oldY = y;
bmDC.SelectObject(pOldbmp);
}
Thanks
|
|
|
|
|
You're not deleting your original un-rotated image.
After you call rotate you should delete it like this.
DeleteObject(hsrcbmp)
|
|
|
|
|
Damn, stupid me.
Looks like it's working now.
Thanks a lot!
|
|
|
|
|
I just finished my initial work and got a Anti Aliased Image Transformation algorithm (dubbed Aaform). It'll be posted here as soon as I can clean it up and make sure I got the bugs out.
You pass it four points and a bitmap and it fits the bitmap to the points using the same concept as Aarot. (had to change the code a little)
|
|
|
|
|
As has been said, this is a very big hammer to hit the nail of rotating pictures of your grandmother.
But to give an example where it may be useful...
I work for a company doing raster scans of aircraft parts, to detect small flaws inside them. You don't want small cracks becoming big cracks and having your wing fall off.
So even small information in very large images is worth keeping. If I can use this algorithm to make a slow, but information-keeping rotation, then my customers will be pleased...
Iain.
|
|
|
|
|
Well, it is a bit of an overkill for an image. I agree. Perhaps this is useful for other systems and simulations?
Programmers working in fields such as medial, electrical, astronomical, nuclear?
I don't know, but I think there might be valuable info for someone here.
I'm voting as if the image bit is only a example and the real value is in some other application.
Cheers
|
|
|
|
|
For square pixels the distance of (center of) the pixel to the neighbouring original pixels is used. I believe it can be shown that for square pixels your method will yield similiar results to that of standard interpolation techniques. Except with one difference. You have made it unnecessarily complicated.
I can imagine that for non square pixels you may have a point.
yalcin
|
|
|
|
|
Teashirt2 wrote: I believe it can be shown that for square pixels your method will yield similiar results to that of standard interpolation techniques
similar but not the same.
I just wanted to show (imho) the ideal method of rotating an image. I don't care how complicated that makes the algorithm.
|
|
|
|
|
I actually don't understand exactly why you did it so complicate!
If it's just a simple rotation, computing how much of a src pixel
goes inside a dest pixel should be equivalent to bilinear
interpolation.
Moreover, considering a pixel like having area is just....
looking for trouble.
It is often by far easier to consider pixels like samples with no area.
If you want to scale on the fly that's another problem.
But again, if it's just scaling and rotating, you could
filter, then rotate with bilinear interpolation.
The problem might be much more involved for complicate projections,
like shearing, omographies, in which cases you ideally need per pixel
filtering.
Always in the case I did not miss anything from your article.
Cheers,
Luca.
|
|
|
|
|
Luca Piccarreta wrote: I actually don't understand exactly why you did it so complicate!
Should it matter how complicated my code is? The point is the Aarot rotates images perfectly (as perfect as they can get on a computer)
Luca Piccarreta wrote: If it's just a simple rotation, computing how much of a src pixel
goes inside a dest pixel should be equivalent to bilinear
interpolation.
It might come close
Luca Piccarreta wrote: Moreover, considering a pixel like having area is just....
looking for trouble.
Well if you want to get the best quality images possible that is what you have to do.
Luca Piccarreta wrote: The problem might be much more involved for complicate projections,
like shearing, omographies, in which cases you ideally need per pixel
filtering.
Aarot only rotates images. True, trying to treat a pixel like a square is tricky, but that doesn't make it somehow wrong to do it.
Luca Piccarreta wrote: Always in the case I did not miss anything from your article.
I think you missed that I'm not trying to show you an efficient, yet good quality algorithm, I'm demonstrating how an image can be rotated perfectly without compensation for speed.
|
|
|
|
|
> I think you missed that I'm not trying to show you an efficient,
> yet good quality algorithm, I'm demonstrating how an image can be
> rotated perfectly without compensation for speed.
No, you showed a good quality but pervert way of doing a
trivial job, trust me.
You say perfect... no, there is not such thing as perfection,
more nice-looking filters exist, such as bicubic, trilinear,
or even edge adaptive filters.
Consider googling around a little bit for image processing
tutorials.
A digital image is a sampling of a filtered (by the lens and
the CCD area) continuous image.
The screen output is a (spatio-temporal) sample and hold
interpolation of a digital discrete signal.
This is how all the world sees it.
But feel free to do it as you wish.
Luca.
|
|
|
|
|
> A digital image is a sampling of a filtered (by the lens and
the CCD area) continuous image.
Actually, it's a sampling of definite integrals of a filtered continuous signals, each pixel takes the value of the area under the curve for a specific range of coordinates (x->x') and (y->y') divided by (x'-x)*(y'-y).
And while there is no such a thing as a perfect (ie, reversible) rotation sampled again through the original (unrotated) sampling function - such as rotation of a computer image - except for a handful of rotation parameters, there *is* such a thing as an information theoretically ideal rotation. That is the rotation that loses the least information and introduces the least *new* information (ie, moves the energy of the curve around introducing the least entropy).
The algorithm presented looks like it may well be "ideal" in the mathematical sense - but it may not be, it can be hard to tell without looking carefully. It is certainly only useful to information theorists and, possibly, abnormally risk averse printing firms.
|
|
|
|
|
maihem wrote: Actually, it's a sampling of definite integrals of a filtered continuous signals, each pixel takes the value of the area under the curve for a specific range of coordinates (x->x') and (y->y') divided by (x'-x)*(y'-y).
Even considering the integral, it's still a linear filter (assuming a
linear sensor), anyway.
maihem wrote: And while there is no such a thing as a perfect (ie, reversible) rotation sampled again through the original (unrotated) sampling function - such as rotation of a computer image - except for a handful of rotation parameters, there *is* such a thing as an information theoretically ideal rotation. That is the rotation that loses the least information and introduces the least *new* information (ie, moves the energy of the curve around introducing the least entropy).
The algorithm presented looks like it may well be "ideal" in the mathematical sense - but it may not be, it can be hard to tell without looking carefully. It is certainly only useful to information theorists and, possibly, abnormally risk averse printing firms.
Never seen it this way, but it might be interesting.
Any link?
|
|
|
|
|
> Even considering the integral, it's still a linear filter (assuming a
linear sensor), anyway.
Doh, of course it is. Silly me. The integral is just in the filter.
[stuff about information and entropy snipped]
> Never seen it this way, but it might be interesting.
> Any link?
Not off hand. Search for "Shannon", "information" and "entropy" for a starting place.
Unfortunately, I am not an expert in information theory and don't wholly understand it (I didn't continue into postgraduate study). Information theory seems to be pretty hard stuff - even getting into the realms of cutting edge physics.
|
|
|
|
|
Are not pixels simply approximations of what is really there? Then what we have is a perfect rotation of an approximate representation. Would not the original approximation contain aliasing, thus degrading the value of it in the first place?
I cannot believe that a representation is the correct place to start as input data. Its like pumping RF into your 'perfect' big screen TV, the component video is better. I think this is a basic flaw in approach.
I do commend the article as worthwhile. Nicely done.
|
|
|
|
|