TJpegImage: Internal bitmap not updated after applying JPEG compression - delphi

I want to convert a BMP to JPG, compress that JPG and the put back the compressed JPG into the original BMP.
However, it won't assign the compressed image to the BMP. I always get the orignal image into the BMP.
The code is below. To see the compression I set CompressionQuality = 1. This will literary ruin the image.
function CompressBmp2RAM(InOutBMP: TBitmap): Integer;
VAR
Stream: TMemoryStream;
Jpg: TJPEGImage;
begin
Jpg:= TJPEGImage.Create;
Stream:= TMemoryStream.Create;
TRY
Jpg.Assign(InOutBMP);
Jpg.CompressionQuality:= 1; // highest compression, lowest quality
Jpg.Compress;
Jpg.SaveToStream(Stream);
//Stream.SaveToFile('c:\out.jpg'); <---- this gives the correct (heavily compressed) image
Result:= tmpQStream.Size;
InOutBMP.Assign(Jpg);
//InOutBMP.SaveToFile('c:\out.bmp'); <---- this gives the uncompressed image
FINALLY
FreeAndNil(Stream);
FreeAndNil(Jpg);
END;
end;
I have found an work around, but I still want to know why InOutBMP.Assign(Jpg) in the code above won't work.
...
Stream.Position:= 0;
Jpg.LoadFromStream(Stream);
InOutBMP.Assign(Jpg);
...
To me it seems to be a bug. The JPG is not aware that the data was recompressed, so the internal bitmap is never updated. There should be some kind of internal "DirtyData" (or "HasChanged") flag.
So, what is the official solution for this?
Having the JPG to reload ITS OWN DATA from an external data source (stream) seems rather a hack/temporary bug fix.
PS: Jpg.DIBNeeded won't help.

I just checked the code of TJpegImage, and the hypothesis I posted in the comments seems correct.
TJpegImage keeps an internal TBitmap for the representation. When you call DIBNeeded, this bitmap is created based on the Jpeg image data.
GetBitmap (the private function that does the legwork for DIBNeeded) will first check if the bitmap is already assigned, and won't repeat the process if it is. So just calling DIBNeeded will not work in your case, since you're basically guaranteed to have this cached bitmap already.
The FreeBitmap method will free the internal bitmap, after which calling DIBNeeded will create a new one again. So I think the sequence you need is:
Jpg.Compress; // Make sure the Jpeg compressed image data is up to date
Jpg.FreeBitmap; // Clear the internal cached bitmap
Jpg.DIBNeeded; // Optional, get a new bitmap. Will happen when you assign to TBitmap.
I also mentioned JpegNeeded before, but that will do a similar thing as DIBNeeded: check if there is data, if not, call Compress. So you need to call Compress, like you did, to force this compression.
PS: TBitmap (and file formats similar to bmp), don't really know this kind of compression, so by assigning it back to the bitmap, you will have reduced image quality, but not image size. Some bitmap formats, including PNG, do compress by using (amongst others) run length encoding (RLE), which means something like spending just four bytes for saying "And now, 54 times a pixel of this color!". That kind of compression won't work really well on images with lots of jpeg artifacts (the grainy/blurry side effect of the compression), so a PNG version of the compressed Jpg might be larger than a PNG version of the original, even though the quality of the original is better as well. This is especially true for images with large areas of the same color, like screenshots and certain artwork.

The internal TJPEGIMage.GetBitmap function only creates an internal bitmap based on the current jpeg image if no internal bitmap has been previously created.
Assign Image A. Do not use Canvas.
Assign Image B. Use Canvas and see Image B.
Assign Image C. Use Canvas and see Image B.
Assign Image D. Use Canvas and see Image B.
etc.
This is definitely a bug in TJPEGImage. I'm using XE7, so maybe this has been fixed by now.
My workaround to always get the correct JPEGImage.Canvas bitmap is to clear any existing internal bitmap before the assignment.
TJPEGImage = class(Vcl.Imaging.jpeg.TJPEGImage)
public
procedure Assign(Source: TPersistent); override;
end;
procedure TJPEGImage.Assign(Source: TPersistent);
begin
FreeBitmap;
inherited;
end;
The code above is helpful when using one TJPEGImage to handle a lot of different images. For only a few images, creating a new TJPEGImage for each image works.

Related

Delphi: GR32 draw a PNG with alpha onto a TBitmap32 without clearing its content

After going through several other related questions I couldn't come up with a working code for this, so please spare the "duplicate question" tags.
Given a PNG image with either per-pixel alpha channel or single-color transparency, I need code to draw it onto a TBitmap32 which already contains an image (some drawing goes on before the PNG part). So let's say my TBitmap32 is 200x200, I do some drawing on it, then I want to ~insert a smaller transparent PNG image on top of its current content, transparently according to the PNG's alpha channel data or single-color alpha.
Uses pngimage, GR32;
procedure TForm1.Button1Click(Sender: TObject);
Var b: TBitmap;
b32: TBitmap32;
p: TPngImage;
begin
b := TBitmap.Create;
b32 := TBitmap32.Create;
p := TPngImage.Create;
// 50x50 PNG
p.LoadFromFile('z:\test2.png');
b.Width := 200;
b.Height := 200;
b32.Width := 200;
b32.Height := 200;
// some drawing happens on the b32~
// insert code here to draw the png onto the b32, on top of
// what's already drawn, and at specific coordinates i.e 10,10
/////////////////////////////
b32.DrawTo(b.Canvas.Handle,0,0);
Canvas.Draw(0,0,b);
p.Free;
b32.Free;
b.Free;
end;
Original PNG:
Results so far:
There are two ways of working with transparent PNG files:
Load them into intermediary TBitmap32 bitmaps and then manipulate these TBitmap32 bitmaps.
Use TPngImage.Draw (implemented in Vcl.Imaging.pngimage with Delphi XE2 and later) directly on target Canvas, as you have pointed out.
The second way is preferable when it comes to transparency, because the code that you may find to load a PNG into TBitmap32 may work incorrectly. Here are the two examples of the incorrect code that is used most frequently:
(1) “LoadPNGintoBitmap32” from http://graphics32.org/wiki/FAQ/ImageFormatRelated
- it applies the transparency twice, so the images with alpha values other than 0 or 255 will look differently than in other software (most noticeable on translucent images with glass effects). This code will first apply alpha to RGB and then sets alpha, so when you pain, alpha will be applied again. You can find more information on this issue here: Delphi, GR32 + PngObject: converting to Bitmap32 doesn't work as expected
. Besides that, it doesn't convert correctly transparency from paletted images into the alpha layer of TBitmap32, for example, all white pixels become transparent.
(2) “LoadBitmap32FromPNG” from gr32ex library: https://code.google.com/archive/p/gr32ex/
- a slightly different implementation of the same algorithm as (1), and has the same issues as (1).
If you still prefer using TBitmap32, make the following sequence of steps:
Make sure your code correctly converts PNG to TBitmap32.
Do not use TBitmap32 with transparent images to draw directly on HDC, Canvas or TBitmap. Use dmBlend and DrawTo or BlockTransfer() to draw on another TBitmap32. For example, to draw transparently on a TBitmap, create an intermediary cache TBitmap32:
Copy the image from TBitmap to the cache TBitmap32;
Apply your transparent image to the cache TBitmap32 using DrawTo or BlockTransfer(), avoid using Canvas or HDC to mix two images because they lose alpha layer information;
Copy the image back from the cache TBitmap32 to your TBitmap.

Storing TBitmap in TMetaFile for smooth scaling in RTF doubles the image size

The RTF image support is very limited (Windows support, not just in Delphi), other formats than bitmaps and metafiles work but are not displayed correctly by RichEdit control.
One thing I noticed is when Microsoft Word image is copied and pasted into RTF it scales
smoothly as opposed to pasting image manually (as a bitmap).
The reason for that is that Word keeps internally a scaled preview of an image in Metafile format (along with original image) and this scaled version is copied and pasted to RTF and apparently RTF renders MetaFile images smoothly when scaled in RichText editor.
Seems like a good workaround and after implementing embedding BMP in WPF function I noticed one problem I cannot get around: the resulting WMF is double the size of a bitmap. It looks like WMF stores paint buffer or a second copy of the image.
The code:
procedure DoCopyImage(AGraphic: TGraphic; AWidth, AHeight: Integer);
var
mf: TMetafile;
mfc: TMetafileCanvas;
r: Cardinal;
begin
mf := TMetafile.Create;
try
mf.Enhanced := True;
mf.SetSize(AWidth, AHeight);
mfc := TMetafileCanvas.Create(mf, 0);
try
// set clipping region to a whole image
r := CreateRectRgn(0, 0, AWidth, AHeight);
try
SelectClipRgn(mfc.Handle, r)
finally
DeleteObject(r);
end;
if (AGraphic.Width = AWidth) and (AGraphic.Height = AHeight) then
mfc.Draw(0, 0, AGraphic)
else
mfc.StretchDraw(Rect(0, 0, AWidth, AHeight), AGraphic);
finally
mfc.Free;
end;
// Clipboard.Assign(mf);
mf.SaveToFile('C:\4MB_MetaFile_Why.wmf');
finally
mf.Free;
end;
end;
I call it using TBitmap as TGraphic:
pic := TPicture.Create;
pic.LoadFromFile('C:\2MB_24bpp_Bitmap.bmp');
bmp := Graphics.TBitmap.Create;
bmp.Assign(pic.Graphic);
bmp.Dormant; // experimentation
bmp.FreeImage; // experimentation
DoCopyImage(bmp, bmp.Width, bmp.Height);
Can somebody find an explanation for this behaviour? Is WMF storing paint buffer along with bitmap? How to prevent it?
As to why your sizes may be different - once you Draw to the metafile you are turning over the responsibility to the Metafile for saving out the data. Your bit depth could be different in the output. I don't know for sure but I would also wonder if the StretchDraw call ends up saving the original input or if it saves a bitmap with the new number of pixels. If the image is smaller than the size stretch draw call that could explain the difference. You will also have some overhead in the metafile that will not be in the saved bitmap although that should be minimal.
You may want to look at the MetaFile Explorer. It is a tool that will show you the different draw commands that are embedded in the metafile. I tried your code and looked at the resulting image in MetaFileExplorer. The size of the embedded image looked OK to me. Look at the EMR_STRETCHBLT.cbBitsSrc size. However, I do see the size difference you are reporting so something is taking that space.
You stated:
The reason for that is that Word keeps internally a scaled preview of an image in Metafile format (along with original image) and this scaled version is copied and pasted to RTF and apparently RTF renders MetaFile images smoothly when scaled in RichText editor.
I question this assumption a little bit. A bitmap (any raster image) will show different scaling artifacts depending on how the scaling is performed. The Image Scaling Wikipedia page has some good examples of the differences.
When you write a bitmap into a metafile you are then letting the metafile perform the scaling when the image is drawn to the screen. Different algorithms used by the metafile drawing code vs. the RTF drawing code will cause the output to look different. However there is nothing special about a metafile that can't be done with a normal bitmap. In both cases the original pixels need to be resized/resampled.
Metafiles were really intended for something different than just embedding a single bitmap image. Here is a good Windows Metafile FAQ that explains some of the differences. Basically if you define lines, shapes, and text you can get really smooth scaling because you are describing the drawing, not storing individual pixels.
The key part to getting a good looking scaled image is to pick the right scaling routine. I have used the Graphics32 library for this in my application. The standard StretchDraw routines are designed to be fast - not high quality. When getting ready to draw to the screen I pick a Graphics32 resampler that gives me the results I want. This can change depending on the sizes. For example is your final output larger or smaller than the input image. I resize the image to the final output size and then just Draw instead of StretchDraw.
add this code before your mf.SaveToFile('C:\4MB_MetaFile_Why.wmf');
mf.MMHeight := Round(mf.Height / Screen.PixelsPerInch * 2540);
mf.MMWidth := Round(mf.Width / Screen.PixelsPerInch * 2540);

Delphi, GR32 + PngObject: converting to Bitmap32 doesn't work as expected

I'm using GR32 for drawing multiple semi-transparent PNG images.
So far I've been using the following method:
png:= TPNGObject.Create;
png.LoadFromFile(...);
PaintBox321.Buffer.Canvas.Draw(120, 20, png);
however I wanted to switch to the method proposed on GR32 website (http://graphics32.org/wiki/FAQ/ImageFormatRelated) :
tmp:= TBitmap32.Create;
LoadPNGintoBitmap32(tmp, ..., foo);
tmp.DrawMode:= dmBlend;
PaintBox321.Buffer.Draw(Rect(20, 20, 20+ tmp.Width, 20+tmp.Height),
tmp.ClipRect, tmp);
While the first method works perfectly fine, the second - which should give the same result - causes very strange problem with alpha channel, see the image (which also shows comparison to the same image "arranged" in Paint.NET - both background and icon were opened on the layers of the editor). The image depicts that the Bitmap32 is loaded or drawn inproperly. Any tips?
-- added 22 Nov
I've found out that it is not about drawing, it's about loading PNG to BMP32. Saving back from BMP32 to PNG generates the incorrect, "whitened" (the one on the left) PNG image.
The reason seems to be that the transparency is applied two times to the image when loaded with LoadPNGintoBitmap32, giving it a more transparent and greyish look (more on this later).
First the transparency:
This is code from the original LoadPNGintoBitmap32, the critical parts are marked with comments:
PNGObject := TPngObject.Create;
PNGObject.LoadFromStream(srcStream);
destBitmap.Assign(PNGObject); // <--- paint to destBitmap's canvas with transparency (!)
destBitmap.ResetAlpha;
case PNGObject.TransparencyMode of // <--- the following code sets the transparency again for the TBitmap32
{ ... }
The destBitmap.Assign internally does the same as you in your previous approach: it let's the PNG image paint itself to its canvas. This operation respects the alpha channel of the PNG. But this is not necessary, since the alpha channel is assigned to TBitmap32's pixels in a second step!
Now change the code as follows, critical parts are again marked with comments:
PNGObject := TPngObject.Create;
PNGObject.LoadFromStream(srcStream);
PNGObject.RemoveTransparency; // <--- paint PNG without any transparency...
destBitmap.Assign(PNGObject); // <--- ...here
destBitmap.ResetAlpha;
srcStream.Position:=0;
PNGObject.LoadFromStream(srcStream); // <--- read the image again to get the alpha channel back
case PNGObject.TransparencyMode of // <--- this is ok now, the alpha channel now only exists in the TBitmap32
{ ... }
The above solution is inefficient because it reads the image twice. But it shows why your second approach produces a more transparent image.
And for the greyishness: There is one more problem in the original code: destBitmap.Assign first fills the background with clWhite32, then paints the image transparently onto it. And then LoadPNGintoBitmap32 comes and adds another layer of transparency on top of it.
The problem may be that the PNG has incorrectly converted to TBitmap32, losing the transparency information in transit. It is a common case with paletted PNG images. Otherwise, you would not had to use „Bitmap.DrawMode := dmTransparent” and the „OuterColor”. If the transparencry information from PNG would have correctly transferred to TBitmpa32, DrawMode := dmBlend would have worked, without the need to set the OuterColor.
What matters most is how did you load a PNG into the TBitmap32. The TPngImage from Vcl.Imaging.pngimage unit (implemented in Delphi XE2 and later) can draw transparently on bitmaps, preserving what was on that bitmaps, combining colors using the PNG alpha layer, etc, but it doesn’t allow to easily convert various formats of PNG transparency (including paletted) into the alpha component of each pixel of TBitmap32. Once TPngImage have drawn an image, you get the combined RGB for each pixel, but the alpha component is not transferred to the target bitmap.
There are helper routines available that try to load a PNG into a TBitmap32 with transparency, but they have drawbacks:
(1) “LoadPNGintoBitmap32” from http://graphics32.org/wiki/FAQ/ImageFormatRelated
- it applies the transparency twice, so the images with alpha values other than 0 or 255 will look differently than in other software (most noticeable on translucent images with glass effects). This code will first apply alpha to RGB and then sets alpha as a separate layer, so when you paint, alpha will be applied again. You can find more information on this issue here: Delphi, GR32 + PngObject: converting to Bitmap32 doesn't work as expected
. Besides that, it doesn't convert correctly transparency from paletted images into the alpha layer of TBitmap32. They manually set alpha transparency for the pixels of a certain color of the output bitmap (rendered to RGB) rather doing that before rendering to RGB, so the actual transparency is lost as on your sample image when all white pixels are transparent.
(2) “LoadBitmap32FromPNG” from gr32ex library: https://code.google.com/archive/p/gr32ex/
- a slightly different implementation of the same algorithm as (1), and has the same issues as (1).
So, the solutions are:
Do not use TBitmap32; use Vcl.Imaging.pngimage.TPngImage do draw directly on target bitmap (screen, etc.) – this is the most compatible way that deals correctly with various PNG formats.
Use a helper routing to transfer transparency information from Vcl.Imaging.pngimage.TPngImage to TBitmap32.
Use the GR32 PNG library that can natively load a PNG into TBitmap32 https://sourceforge.net/projects/gr32pnglibrary/
Since you now have all the information on this issue, you may get the right solution for you.
How to load the alpha layer in one pass
Heinrich Ulbricht made a nice suggestion to remove the transparency layer before paining and then to read the image again. To avoid loading the image twice, you can save the alpha layer before calling PNGObject.RemoveTransparency. Here is the code that correctly applies the alpha layer and loads the image only once. Unfortunately, it does not work with paletted images. If you know how to correctly fill the alpha layer of TBitmap32 from any paletted image, without the effects described at Transparent Png to TBitmap32 please let me know.
procedure LoadPNGintoBitmap32(DstBitmap: TBitmap32; SrcStream: TStream; out AlphaChannelUsed: Boolean);
var
PNGObject: TPngImage;
PixelPtr: PColor32;
AlphaPtr: PByte;
SaveAlpha: PByte;
I, AlphaSize: Integer;
begin
AlphaChannelUsed := False;
PNGObject := TPngImage.Create;
try
PNGObject.LoadFromStream(SrcStream);
AlphaPtr := PByte(PNGObject.AlphaScanline[0]);
if Assigned(AlphaPtr) then
begin
AlphaSize := PNGObject.Width * PNGObject.Height;
if AlphaSize <= 0 then raise Exception.Create('PNG files with zero dimensions are not supported to be loaded to TBitmap32');
GetMem(SaveAlpha, AlphaSize);
try
Move(AlphaPtr^, SaveAlpha^, AlphaSize);
PNGObject.RemoveTransparency;
DstBitmap.Assign(PNGObject);
DstBitmap.ResetAlpha;
PixelPtr := PColor32(#DstBitmap.Bits[0]);
AlphaPtr := SaveAlpha;
for I := 0 to AlphaSize-1 do
begin
PixelPtr^ := (PixelPtr^ and $00FFFFFF) or (TColor32(AlphaPtr^) shl 24);
Inc(PixelPtr);
Inc(AlphaPtr);
end;
finally
FreeMem(SaveAlpha, AlphaSize);
end;
AlphaChannelUsed := True;
end else
if PNGObject.TransparencyMode = ptmNone then
begin
DstBitmap.Assign(PNGObject);
end else
begin
raise Exception.Create('Paletted PNG images are not supported in LoadPNGintoBitmap32, transparency cannot be stored to TBitmap32');
end;
finally
FreeAndNil(PNGObject);
end;
end;

Loading specific icon size into TIcon from stream

My application downloads and displays favicons for specific websites. I followed Bing's solution for detecting image format from stream, but have hit another snag. Assuming an actual icon image, the code goes like this:
var
icon : TIcon;
begin
icon := TIcon.Create;
try
icon.LoadFromStream( faviconStream );
spFavicon.Glyph.Assign( icon );
finally
icon.Free;
end;
end;
(spFavicon is TRzGlyphStatus from Raize Components. Its Glyph property is a TBitmap)
Now, this works, but sometimes the downloaded icon contains multiple images in different sizes, e.g. 32x32 in addition to the expected 16x16. For some reason the control's Glyph property picks the larger size.
How can I load only the 16x16 size into TIcon, or from TIcon into TBitmap?
Test favicon: http://www.kpfa.org/favicon.ico
On edit: If at all possible, I'd rather avoid saving the icon to a file first.
The primary source for the file format of an .ico file is on MSDN. You should be able to work it out from this.
The ReadIcon procedure in Graphics.pas may be of use but I imagine that you only need to find 16x16 since you are looking for favicons.
If you wanted to get really cute, you could download the source to, say, Firefox, and see exactly how they handle favicons.

Extracting PNG images from Delphi 2009 imagelist

The TImageList of Delphi 2009 has support for PNG images by adding them in the imagelist editor. Is there any way to extract a TPngImage from a TImagelist and preserving the alpha channel?
What I want to do is actually to extract the images from one TImageList, make a disabled version of them and then add them to another TImageList. During this operation I would of course like to preserve the alpha channel of the PNG images.
I did something like this with Delphi 2006.
TImageList contains a protected method GetImages. It can be accessed using the "protected bug"
type
TGetImageImageList = class (TImageList) // Please use a better name!
end;
You can cast the imagelist to the TGetImageImageList to get to the GetImages.
begin
TGetImageList(ImageList).GetImages(index, bitmap, mask);
end;
Bitmap contains the bitmap and mask is a black and white bitmap that determines the transparant sections.
You now can change the bitmap and store it using:
function Add(Image, Mask: TBitmap): Integer;
I hope this gives you enough pointers to explore further.

Resources