angusj

It's a problem with the Graphics32 library too if TAffineTransformation is used to do the scaling.

If you avoid using TAffineTransformation, and just use a resampler together with a renderer, then you do avoid this issue with pixelation. (In my Image32 graphics library, I use affine transformations without a renderer.)

I've just had another look at resampling and specifically downsampling, and I'm back to my starting assertion that box downsampling does produce better quality images than general purpose resampling algorithms. However, I will concede that, because these downsampled images are generally much smaller, it's usually difficult to spot these differences. For example: This is the fruit image from above that has been resized to 1/3 original using a bicubic resampler: This is the fruit image from above that has been resized to 1/3 original using a box downsampler: Yes, it's hard to spot the differences unless you compare them with a decent image editor (or just zoom in using your web browser). Yet here's a more extreme example of downsampling (scaled to 0.1 of original size) where the quality differences are very noticeable: Bicubic kernel resampler: Box downsampler: Original image: And this does make sense when you understand the differences between these algorithms. Consider downsampling an image to 1/3 its size (where each 3 x 3 grid of pixels will merge into a single pixel) ... box downsampling will weigh every pixel equally in each 3 x 3 grid; whereas general purpose kernel resamplers will heavily weight pixels that are closer to the middle of these 3 x 3 grids.

Indeed, Octree does have significant limitations just as you've illustrated above. Anyhow, here's the image reduced to 16 colors using (a slightly modified) median cut ...

Yes, several bugs needed fixing which I've done and just uploaded. And I'm expecting you'll find a few more 😱. Anyhow, thanks 😁.

This link to the Color Quantization unit in my own Delphi Graphics Library may also be useful to you. The code there should be quite easy to adapt to Graphics32.

https://www.angusj.com/delphitips/getversion.php

MSVS does even better that that, it also suggests how to improve your code. (Well it does for me, but perhaps not for you if your code can't be improved 😜.) Over almost 30yrs, I've written a lot of very useful (ie reuseable) Delphi code, otherwise I would have ditched Delphi years ago.

https://stackoverflow.com/questions/24789766/drawing-a-bezier-curve-using-firemonkey

If you're only searching by filename or file type (*.jpg;*.png; etc) then the filesystem would suffice.

LOL 🤣. The pages perhaps are "cooked" but it wasn't intentional. Anyhow, I've just done a number of followup tests and I'll concede that I can't spot the difference between all 3 renderers when downsampling various images. I'm surprised and I'll need to refresh myself on the differences between these resamplers.

Looking at the image in the OP, it looks like FMX is using a nearest neighbour resampler, which is fast but poor quality. Certainly a bilinear or bicubic resampler would be much better, but for down sampling specifically, a BoxDownSampling resampler would be better still.

Yep, point taken.

Or you could make the bitshifting explicit : inc(Cache.b, (ps.rgbBlue*alpha) shr 2); And given that you're multiplying two bytes you could optimise this further by using a lookup table: MulTable: array [Byte,Byte] of integer; //initialized in initialization section ... inc(Cache.b, MulTable[ps.rgbBlue, alpha] shr 2); Edit: Oops, sorry, it appears that alpha is an integer, not a byte.

4 😁 Edit: Perhaps it just means re-star-ting? Edit2: It's very easy to rename a repository (via Settings) and you won't lose any stars!

Honestly, the "market" for new Delphi components/libraries died about 10 years ago. The only people writing Delphi code now are old timers who've been around since Borland days, and before its lead developer got poached by Microsoft to write C#. So there's no longer a market for third-party Delphi developers, unless they've migrated their code into other languages (usually C#). The only "new" Delphi code is written by old hacks like me who aren't trying to make money out of this.

I was a contributor to Graphics32 for many years, but eventually Graphics32 had become too unweildy for me, and no longer useful over the longer term. My initial inclination was to do a major Graphics32 rewrite/update .. things like pruning 20!! various Line and Lineto methods from TBitmap32. These kind of made sense historically, but made absolutely no sense now. But when I started pruning these methods, I realised I was unravelling a Gordian's knot (ie an almost impossible task). So many of these methods had been interwoven inside other methods that I realised I'd be better off starting from scratch, which is what I did with Image32. Edit: Not that I'm including myself in "all the brilliant people", just a long term programming hack 😜. Edit2: And an expert is just someone who knows an awful lot about very little.

I've been lurking 😜, but when the OP mentioned TImage32, I was pretty sure he was referring to that class in Graphics32, rather than my own Image32 Graphics Library. While Image32 has many similarities with Graphics32, unlike Graphics32 it's cross-platform (using either FPC or Delphi's FMX framwork), and it also supports SVG images (reading not writing) which seems relevant given the parameters in this discussion. Drag and drop isn't something that a graphics library should do, but but rotating (and resizing and transforming etc) most definitely are things any decent graphics library will do. SVG files, as in a library of SVG images, is completely separate from a Graphics (Display) Library, and I'd strongly recommend you source those separately. Anyhow, supporting SVG, even just reading them, is a huge task, but I think I've done a reasonable job of this in my Image32 library. (And Image32 is currently the preferred renderer for SVGIconImageList). As for editing SVG images, that is way beyond the means of a single developer. And while it may seem related to graphics display, it really isn't, and I seriously doubt you'd find a Graphics Libray (in any language) that supported editing SVG images. While Graphics32 is still an excellent library, IMHO it's now showing it's age and the documentation hasn't been updated in a very long time. So unless you've been using the library for a long time (and there are many who have and still are), it won't be easy getting up to speed.

I strongly suspect that this is because you haven't pre-multiplied the image before using AlphaBlend. https://learn.microsoft.com/en-us/windows/win32/api/wingdi/ns-wingdi-blendfunction Here's a (rather poor) example of using AlphaBlend where the image is premultiplied. There's also a PremultiplyAlpha function in my AlphaBitmaps.pas unit.

While I can't guarantee it, this is likely to help: http://www.angusj.com/delphi/image32/Videos/cpp.mkv Absolutely! Edit: The 32 in the library name simply refers to image bits per pixel WRT how images are stored in memory. (And yes the library can read and write images to file using different bpp.)

I've attached a pretty old unit with numerous functions for managing semi-transparent VCL.Graphics.TBitmap controls. However, unless your graphics needs are minimal, I strongly recommend you consider using an open source graphics library. Two graphics libraries for Delphi I can recommend: Graphics32: Multiple developers contributed over the last 20yrs and is widely used. Image32: Recently developed by me. IMHO it's a lot simpler than Graphics32 while almost as fully featured. AlphaBitmaps.pas

https://github.com/EtheaDev/SVGIconImageList

I recently received an email informing me that not all files were appearing in a FileOpen dialog in one of my applications**. And this dialog had absolutely no filtering applied (at least when selecting *.* 😜). The folder given as an example was: C:\Windows\System32\fr-FR And I too wasn't seeing all the files in this folder. Using Delphi 10.4 Update 2 ... I first tried a completely new VCL application with just a TOpenDialog control (without success). I then tried a bare bones console application that's a Delphi translation of this C++ code: https://learn.microsoft.com/en-us/windows/win32/learnwin32/example--the-open-dialog-box program Project2; {$APPTYPE CONSOLE} {$R *.res} uses Windows, SysUtils, ActiveX, ShlObj; var hr: HRESULT; fileOpen: IFileOpenDialog; item: IShellItem; path: LPWSTR; begin hr := CoInitializeEx(nil, COINIT_APARTMENTTHREADED or COINIT_DISABLE_OLE1DDE); if (SUCCEEDED(hr)) then begin // Create the FileOpenDialog object. hr := CoCreateInstance(CLSID_FileOpenDialog, nil, CLSCTX_ALL, IID_IFileOpenDialog, fileOpen); if (SUCCEEDED(hr)) then begin // Show the Open dialog box. hr := fileOpen.Show(0); // Get the file name from the dialog box. if (SUCCEEDED(hr)) then begin hr := fileOpen.GetResult(item); if (SUCCEEDED(hr)) then begin hr := item.GetDisplayName(SIGDN_FILESYSPATH, path); // Display the file name to the user. if (SUCCEEDED(hr)) then begin MessageBoxW(0, path, 'the path', MB_OK); CoTaskMemFree(path); end; //item._Release; end; end; //fileOpen._Release; end; CoUninitialize(); end; end. And this problem persists with only about half the files in the folder (mentioned above) being displayed. However, when I compile the C++ code from the link above in MSVC, the console app. does show all the files (as expected). Any suggestions? **Resource Hacker

Yep, the only author 😁.

I did ask because I was also curious. And a very brief part of the reply was that this user has written an add-on for anther program and states that "I want, eventually, to support multiple languages in the UI". I've really no idea how he plans to do that, and how accessing these files will help. Nevertheless in the past I have used Resource Hacker to glean dialog control ids, menus etc which I've altered dynamically from my own applications (via Windows' messaging system). And on rare occasions I've even altered application resources (modified the files) to better suit my needs - change a menu shortcut, enable a menu item, it tweak a dialog.