I have such code
source.Picture.LoadFromFile(fName);
buffer.Assign(source.Picture.Bitmap);
buffer.Canvas.CopyRect(rect(0,0,buffer.Width,buffer.Height), target.Canvas, rect(0,0,buffer.Width,buffer.Height));
And it won't work.
There are better ways to load image, but I want to play with them.
The main reason is to load smaller images,
So it's correct to copy canvas rect, but it not shows single pixel...
Objects are initialized and scaled except for target which I want to contain more than one image.
I supose there is no need for writing what types are objects, all needed are classes procedures that shows what are what.
I wonder whats wrong? I tried many ways, but simple nothing.
Please help.
Probably source is TImage, buffer is TBitmap, target is also TImage (you should mention it in your question so we don't have to guess).
In this case, the second line would work only when you load from .BMP because only these have bitmap populated. If you have .png or .jpeg instead, the second line would erase the actual picture and replace it with empty bitmap... Not very intuitive behaviour but it's documented at least.
To work with arbitrary graphic, you should use TCanvas.Draw method which in turn calls TGraphic.Draw(). As you can see from description, it draws the graphic you loaded into the canvas at given rectangle. Something like that:
source.Picture.LoadFromFile(fName);
target.Canvas.Draw(0, 0, source.Picture.Graphic);
UPD.
If you want to scale arbitrary picture, it could be done this way:
source.picture.loadFromFile(fName);
buffer.Width := source.picture.Width;
buffer.Height := source.picture.Height;
buffer.PixelFormat := pf24bit;
buffer.Canvas.Draw(0, 0, source.picture.Graphic);
//so we at last have bitmap containing our image in original size
target.Canvas.CopyRect(Rect(0, 0, NewWidth, NewHeight), buffer.canvas, Rect(0, 0, buffer.Width, buffer.Height));
Here NewWidth and NewHeight are image size we want.
By the way, you don't need source: TImage if it is just temporary object to load from file. TPicture would be enough:
var pic: TPicture;
pic := TPicture.Create;
try
pic.LoadFromFile(fName);
...
buffer.Canvas.Draw(0, 0, pic.Graphic);
finally
pic.free;
end;
Related
I am trying to create a Manga viewer which needs to load JPG images with large sizes like 1000*16000, my application is in delphi FMX and i have already tried using TImage, TImageViewer, TImageControl but all of them use TBitmap which trims the size to 8192 after loading the image
I tried searching for image libraries but i was unable to find anything for FMX (firemonkey)
I was thinking maybe i could load the image in a Memory stream and then copy and draw it in smaller sizes to several bitmaps ? but i don't how can i read and parse the memory stream and only pick to a certain clean height !
In the end i'm looking for a way to load and show these large (1000*16000) images in Delphi FMX
I am using delphi 10.2.3
Thanks.
Edit 01 :
I think i have found a way that might make things easy, i added the Vcl.Imaging.jpeg to uses clause in the FMX (FireMonkey) and then i used TJPEGImage and loaded the image, and i printed the width and height and they are correct and not trimmed ! so i was thinking, maybe i can read each pixel from TJPEGImage.canvas and then print it into FMX TBitmap ?, what do you think about this approach ?, do you know a good way to copy the data inside TJPEGImage to FMX TBitmap ?
Edit 02 :
I have found a new solution, the TBitmapSurface, it seems this class doesn't have the TBitmap limitations and i was able to load the image inside of it without getting trimmed ! but there is a problem! how can i give this to TImage ? if i simply say Image.bitmap.assign(TBitmapsurface), then the image gets trimmed again ! so it seems the only possible way is rewriting the TImage so it uses TBitmapSurface instead of TBitmap, any help regarding this issue is appreciated, thanks.
Here is the code for the TBitmapSurface :
bitmapSurf := TBitmapSurface.Create;
TBitmapCodecManager.LoadFromFile(path, bitmapSurf);
Unlike FMX.Graphics.TBitmap which has a size limitations of 8192 * 8192, FMX.Surface.TBitmapSurface seems to support up to 16k * 16k and possibly even more (i haven't tested), so using FMX.Surface.TBitmapSurface you can load the image without getting trimmed, and then you can easily split it into two FMX.Graphics.TBitmap (or possible more parts using the same approach)
Below you can see the code which first loads the JPG into TBitmapSurface, and then the code which splits that into two TBitmap :
var
srce, dest: TBitmapSurface;
path: string;
scan: integer;
w, h1, h2: integer;
begin
path := 'C:\tmp\Imgs\res.bmp';
srce := TBitmapSurface.Create;
TBitmapCodecManager.LoadFromFile(path, srce);
dest := TBitmapSurface.Create;
// first half
w := srce.Width;
h1 := srce.Height div 2;
dest.SetSize(w, h1, TPixelFormat.RGBA);
for scan := 0 to h1-1 do
Move(srce.Scanline[scan]^, TBitmapSurface(dest).Scanline[scan]^, srce.Width * 4);
Image1.Bitmap.Assign(dest);
// second half
h2 := srce.Height - h1;
dest.SetSize(w, h2, TPixelFormat.RGBA);
for scan := h1 to srce.Height-1 do
Move(srce.Scanline[scan]^, TBitmapSurface(dest).Scanline[scan-h1]^, srce.Width * 4);
Image2.Bitmap.Assign(dest);
end;
This answer was provided using the comments on the first post and the answer to my other question:
How to draw FMX.Surface.TBitmapSurface on FMX.Graphics.TBitmap
I am trying to scale images/text etc using MM_ANISTROPIC and what I've done is the following (by the way if the syntax is a little weird, it's originally from delphi so treat the following as pseudocode)
I would expect the following code to produce a rectangle that is 70% of the width of the PaintBox and 30% of the height, yet it doesn't, instead it it noticeably too small.
SetMapMode(hdc,MM_ANISOTROPIC);
SetWindowExtEx(hdc,100,100,0);
SetViewportExtEx(hdc,70,30,0);
Rectangle(hdc, 0,0,PaintBox.width-1,PaintBox.Height-1);
if, on the other hand I change the code so that the SetWindowExtEx has 91 instead of 100 as its parameters (as shown below) then it works, which makes no sense to me at all...
SetMapMode(hdc,MM_ANISOTROPIC);
SetWindowExtEx(hdc,91,91,0);
SetViewportExtEx(hdc,70,30,0);
Rectangle(hdc, 0,0,PaintBox.width-1,PaintBox.Height-1);
My sanity test case was to add the following pseudocode
SetMapMode(hdc,MM_TEXT);
DrawLine(hdc,Round(PaintBox.width*0.7),0,Round(PaintBox.width*0.7),PaintBox.Height-1);
DrawLine(hdc,0,Round(PaintBox.height*0.3),PaintBox.width-1,Round(PaintBox.height*0.3));
I would have expected this to overwrite the lower / bottom edges of my original Rectangle but it does not unless I uses that 91,91 SetWindowExtEx.
Can anyone duplicate this?
FURTHER EDIT: Here is my exact original code I had given pseudo code before to make the question more accessible to non-delphi users but one of my commenters wanted full code to see if my contention that it was a delphi quirk was true or not.
The entire project consisted of a VCL form with a rectangular paintbox dropped on it centered so there was space all around it, and its onPaint event was set to the code below resulting in this image::
procedure TForm11.PaintBox2Paint(Sender: TObject);
var
hdc:THandle;
res:TPoint;
procedure SetupMapMode;
begin
SetMapMode(hdc,MM_ANISOTROPIC);
SetWindowExtEx(hdc,100,100,0);
SetViewportExtEx(hdc,70,30,0);
// These lines are required when we're painting to a TPaintBox but can't be used
// if we're paiting to a TPanel and they were NOT in my original question but only
// got added as part of the answer
// SetViewportOrgEx(hdc,PaintBox2.Left,PaintBox2.Top,#ZeroPoint);
// SetWindowOrgEx(hdc,0,0,#ZeroPoint);
end;
begin
//draw a rectangle to frame the Paintbox Surface
PaintBox2.Canvas.Pen.Style:=psSolid;
PaintBox2.Canvas.Pen.width:=2;
PaintBox2.Canvas.Pen.Color:=clGreen;
PaintBox2.Canvas.Brush.Style:=bsClear;
PaintBox2.Canvas.Rectangle(0,0,PaintBox2.Width-1,PaintBox2.Height-1);
PaintBox2.Canvas.Brush.Style:=bsSolid;
//initialize convenience variable
hdc:=PaintBox2.Canvas.Handle;
SetTextAlign(hdc,TA_LEFT);
//as doing things to the PaintBox2.Canvas via Delphi's interface tends to reset
//everything, I'm ensuring the map mode gets set **immediately** before
//each drawing call
SetupMapMode;
/// Draw Text at the bottom of the PaintBox2.Canvas (though as it's mapped it
/// SHOULD be 1/3 of the way down and much smaller instead)
TextOut(hdc,200,PaintBox2.Height-PaintBox2.Canvas.TextHeight('Ap'),'Hello, World!',13);
PaintBox2.Canvas.Pen.Color:=clblue;
PaintBox2.Canvas.Brush.Style:=bsClear;
//ensure it's set before doing the rectangle
SetupMapMode;
// Redraw the same rectangle as before but in the mapped mode
Rectangle(hdc, 0,0,PaintBox2.Width-1,PaintBox2.Height-1);
PaintBox2.Canvas.Brush.Style:=bsSolid;
//reset the map mode to normal
SetMapMode(hdc,MM_Text);
//draw text at the "same" position as before but unmapped...
TextOut(hdc,200,PaintBox2.Height-PaintBox2.Canvas.TextHeight('Ap'),'Goodbye, World!',15);
//Draw lines exactly at 70% of the way across and 30% of the way down
//if this works as expected they should overwrite the right and bottom
//borders of the rectangle drawn in the mapped mode
PaintBox2.Canvas.Pen.Color:=RGB(0,255,255);
PaintBox2.Canvas.MoveTo(Round(PaintBox2.Width*0.7),0);
PaintBox2.Canvas.LineTo(Round(PaintBox2.Width*0.7),PaintBox2.Height);
PaintBox2.Canvas.MoveTo(0,Round(PaintBox2.Height*0.3));
PaintBox2.Canvas.LineTo(PaintBox2.Width,Round(PaintBox2.Height*0.3));
end;
Okay, I don't know WHY the following is necessary -- it may be a Delphi quirk, the fact that I'm using a TPaintBox with is a TGraphicControl rather than a Component, or if I'm missing out on some fundamental concept on how this whole mapping mode works, BUT if I add the following code:
ZeroPoint:=TPoint.Zero;
SetViewportOrgEx(hdc,PaintBox1.Left,PaintBox1.Top,#ZeroPoint);
SetWindowOrgEx(hdc,0,0,#ZeroPoint);
Then it all displays as expected. Anyone have any explanations as to why this is necessary?
EDIT: Okay, I've got a PARTIAL explanation. It has to do with the control I was painting on being a TPaintBox, which is a TGraphic control rather than a TWinControl. To wit:
TGraphicControl is the base class for all lightweight controls.
TGraphicControl supports simple lightweight controls that do not need the ability to accept keyboard input or contain other controls. Since lightweight controls do not wrap Windows screen objects, they are faster and user fewer resources than controls based on TWinControl.
As such, although they APPEAR to have a separate canvas, I have this sneaking feeling that they are really sharing the form's canvas which is why, when I switched to a TWinControl descendant, which DOES own its own Windows DC, then the display worked as expected without setting the ViewpointOrg.
So it was a Delphi quirk after all...!
I try to build image. Pixel by pixel. So first I build some class which can draw by loops different color at each pixel. But it works nice only if alpha is set to 255. Changing alpha makes colors darker and changes picture. Size and place is OK.
var rep:NSBitmapImageRep = NSBitmapImageRep(
bitmapDataPlanes: nil,
pixelsWide: width,
pixelsHigh: height,
bitsPerSample: 8,
samplesPerPixel: 4,
hasAlpha: true,
isPlanar: false,
colorSpaceName: NSDeviceRGBColorSpace,
bytesPerRow: 0,
bitsPerPixel: 0)!
for posX in 0-offset...width+offset*2-1 {
for posY in 0-offset...height+offset*2-1 {
var R = Int(Float(posX)/Float(width)*255)
var G = Int(Float(posY)/Float(height)*255)
var B = Int(rand() % 256)
pixel = [R,G,B,alpha]
rep.setPixel(&pixel, atX: posX, y: posY)
}
}
rep.drawInRect(bounds)
alpha set to 255
alpha set to 196
alpha equals 127 this time.
And 64.
Where i'm wrong?
The most likely problem is that you're not premultiplying the alpha with the color components.
From the NSBitmapImageRep class reference:
Alpha Premultiplication and Bitmap Formats
When creating a bitmap using a premultiplied format, if a coverage
(alpha) plane exists, the bitmap’s color components are premultiplied
with it. In this case, if you modify the contents of the bitmap, you
are therefore responsible for premultiplying the data. Note that
premultiplying generally has negligible effect on output quality. For
floating-point image data, premultiplying color components is a
lossless operation, but for fixed-point image data, premultiplication
can introduce small rounding errors. In either case, more rounding
errors may appear when compositing many premultiplied images; however,
such errors are generally not readily visible.
For this reason, you should not use an NSBitmapImageRep object if you
want to manipulate image data. To work with data that is not
premultiplied, use the Core Graphics framework instead. (Specifically,
create images using the CGImageCreate function and kCGImageAlphaLast
parameter.) Alternatively, include the
NSAlphaNonpremultipliedBitmapFormat flag when creating the bitmap.
Note
Use the bitmapFormat parameter to the
initWithBitmapDataPlanes:pixelsWide:pixelsHigh:bitsPerSample:samplesPerPixel:hasAlpha:isPlanar:colorSpaceName:bitmapFormat:bytesPerRow:bitsPerPixel:
method to specify the format for creating a bitmap. When creating or
retrieving a bitmap with other methods, the bitmap format depends on
the original source of the image data. Check the bitmapFormat property
before working with image data.
You have used the -init... method without the bitmapFormat parameter. In that case, you need to query the bitmapFormat of the resulting object and make sure you build your pixel values to match that format. Note that the format dictates where the alpha appears in the component order, whether the color components are premultiplied by the alpha, and whether the components are floating point or integer.
You can switch to using the -init... method that does have the bitmapFormat parameter and specify NSAlphaNonpremultipliedBitmapFormat mixed in with your choice of other flags (first or last, integer or floating point, endianness). Note, though, that not all possible formats are supported for drawing.
By the way, I strongly recommend reading the sections about NSImage and NSBitmapImageRep in the 10.6 AppKit release notes. Search for "NSImage, CGImage, and CoreGraphics impedance matching" and start reading there through the section "NSBitmapImageRep: CoreGraphics impedance matching and performance notes", which is most relevant here. That last section, in particular, has important information about working directly with pixels.
I have an existing buffer full of (DIB) bitmap data, i.e. width x height x 4 bytes (RGBA) in size. What I want to do is draw this bitmap to the screen, but looking at the CreateBitmap... / CreateDIB... functions, they don't appear to do what I'm looking for. I don't want to copy the memory in, I want to retain access to it, so I can continue to write to it in the next frame (without incurring a penalty for copying the data). Does such a method exist, or do I have to create a new bitmap and call SetDIBits on it?
If you want simple code, then you can use a BITMAP structure and assign it's bmBits to point to your actual image data (RGBA 8-Bit).
Then you can use GDI method
HBITMAP CreateBitmapIndirect(const BITMAP *pbm);
to create HBITMAP for displaying the image to screen.
But actually I think the system still do the copying while creating HBITMAP, that's why after CreateBitmapIndirect returns, you can safely free your image data.
But at least you only have to create the buffer once, and using it repeatedly as long as the size of the image doesn't change.
I use this method to display raw video from RED's Camera.
You can't write a DIB directly to a device context - you'll have to create a bitmap and copy the pixels in. Annoying, I know!
Looks like this question has a succinct way of doing that in the accepted answer.
For my graphics class, I need to match an OpenGL sample output in a pixel-perfect way.
I figured it would be cool if I could spawn the sample, send it some input, then take a screenshot of the exact OpenGL area, do the same for mine, and then just compare those screenshots. I also figured something like AutoIT would be the easiest way to do something like this.
I know that I can use the screencapture function, but I'm unsure of how to get the exact coordinates and size of the OpenGL area of the window (not the title bar/surrounding window stuff).
If anybody could help me out that would be awesome.
Or if anybody can think of an easier solution than AutoIt, and can point me in the right direction, that'd be great too.
EDIT: I also don't have access to the source code of the sample output program.
AutoIt is a pretty good tool for this job. I think you already found the _ScreenCapture in the help file, it has parameters for: X left, Y top, X right and Y bottom coordinates. However, the _ScreenCapture function stores to a file. I've made a library where you can capture part of the screen, or a window, and save this to memory. Then you can get the pixel colors from the memory and compare them to your existing pixels. You can find it here: http://www.autoitscript.com/forum/topic/63318-get-or-read-pixel-from-memory-udf-pixelgetcolor-au3/
The part of a window which does not include the titlebar and the borders is called the 'client area'. You can get the width and the height of the client area with the WinGetClientSize. Alternatively, you can use ControlGetPos on the OpenGL control to get the X and Y relative to the window, and the width and height of the OpenGL control. Combined with WinGetPos you should be able to calculate the values you need for _ScreenCapture. You should be able to find out a good approach if you use the "AutoIt window info" tool.
Finally, a simple and short solution which gives you little control, but might be just what you need, is the PixelChecksum function. Once you have the coordinates of the OpenGL part, you can use PixelChecksum and get a value corresponding to the pixels of the screen (a checksum of the pixels). You can then compare this value to a pre-recorded value to tell whether the pixels on the screen are exactly the same. Check the Autoit help file of PixelChecksum for an example.
If you want to capture data from an OpenGL buffer, here is how you can do it with legacy OpenGL (version 1.2 or so)
glFinish();
glReadBuffer(GL_FRONT);
glPixelStorei(GL_PACK_ALIGNMENT, 4);
glPixelStorei(GL_PACK_ROW_LENGTH, 0);
glPixelStorei(GL_PACK_SKIP_ROWS, 0);
glPixelStorei(GL_PACK_SKIP_PIXELS, 0);
glReadPixels(ox, oy, w, h, mode, GL_UNSIGNED_BYTE, img);
where:
ox and oy are origin x and y
w and h are width and height
mode is the mode, like GL_BGR if you want to save to BMP
img is a pointer to unsigned int * to copy the image to
You can search for glReadPixels on the internet and see the reference for more information.