Anders Melander

My bad. That should have been: BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/4*3, ImgView.Bitmap.Height/4*3); as a rect is (x1,y1, x2,y2)

I think you forgot the price of a Windows license... I know it's possible to run Windows on a Raspberry Pi, I just don't think it makes sense from a business or performance POW.

If you mean the size of the layer, something like this: // Half size of background bitmap, centered BL.Location := FloatRect(ImgView.Bitmap.Width/4, ImgView.Bitmap.Height/4, ImgView.Bitmap.Width/2, ImgView.Bitmap.Height/2);

Okay, but: And don't include the exe or dcu files in your zip. Also, a description or a mockup of what you expected the result to be would also be needed; I can't read your mind. That said, You are not specifying the size/position of the bitmap layer. The size of the PNG (4774x4345) is much larger than the size of the background (1920x1247). That in itself is not a problem but the size does seem pretty excessive.

That sounds like a horrible idea. Why on earth would you run a desktop/server OS on an embedded device?

Without knowing the size of the base and layer bitmap I can't tell how their relative sizes should be. You have setup the layer scale to follow the base scale (Scaled=True), but have you specified the initial size of the layer? The ugly edges are most likely caused by having DrawMode=dmTransparent. You can experiment with layers and bitmaps using the Imgview_Layers example: If you continue having problems, please create an issue at the Graphics32 issue tracker: https://github.com/graphics32/graphics32/issues Include a minimal, reproducible example.

You don't need to use LoadBitmap32FromPNG; You can just use TBitmap32.LoadFromFile directly and let that figure the format out for you. BL.Bitmap.LoadFromFile('button.png'); Also, you should probably be using dmBlend DrawMode instead of dmTransparent: BL.Bitmap.DrawMode := dmBlend; dmTransparent is for color key transparency (like what TBitmap does). dmBlend is for alpha blending. What do you mean? What size is it? What size should it be?

Actually, that bitmap wasn't directed at your implementation in particular - because I haven't tried it; It's just a bitmap that Octree in general has problems with. But, I'll take it; You're welcome 🙂 The problem is that Octree doesn't reduce the root node (the MSB of the RGB, which represent 2^3=8 color cubes), or move colors between adjacent nodes. So lets say you are reducing an 1 billion pixel image with 1 million red/blue colors+1 green pixel. Octree will represent this as a MSB color cube that only contains a single color (green in this case) with a pixel count of 1 and a bunch of other cubes representing the other 1 million colors/1 billion pixels. If you now reduce this to 16 colors (or any other count for that matter) you will end up with green+15 red/blue colors. And that is just one of the problems with Octree. Of course you can tweak Octree to work around the various issues is has but I feel that that is just polishing a turd. That said, Octree is fast so one just have to be aware of the limitations and only use it when performance is more important than fidelity.

That's Octree, right? How does it deal with this, when reduced from 17 to 16 colors:

The quantizer and dithering in GifImg isn't tied the GIF format; It's completely independent. It is limited to max 256 colors though (AFAIR). I don't think you should start by inventing your own quantization algorithm. Start with one of the known ones so you at least can learn the problem space first (and avoid the usual mistakes). Here's a few links to get you started: RgbQuant.js: color quantization lib https://github.com/leeoniya/RgbQuant.js nQuantCpp: top 6 color quantization algorithms https://github.com/mcychan/nQuantCpp/ Top 3 color quantization algorithms (same author as above, older article) https://www.blackslate.io/articles/color-quantization-algorithm A good one to start with is Xialoin Wu's algorithm (https://www.ece.mcmaster.ca/~xwu/cq.c) It performs well, with good results, and the algorithm is fairly simple. I think that is also the one I will implement next (when I get time; there's far to many interesting projects to work on). This one is also a good read: https://bottosson.github.io/posts/colorwrong/ I will see if I can find time to wrap some code up for you. It's a pluggable framework so you can extend it with new quantization, dithering, and color lookup algorithms, and color spaces. As far as I remember there are no dependencies on Graphics32. Here it is in action (using Linear RGB color space AFAIR):

https://github.com/graphics32/graphics32/blob/78279b925c6110000666af7b3b48e76090f36289/Source/GR32_Blend.pas#L137 https://graphics32.github.io/Docs/Units/GR32_Blend/Routines/ColorScale.htm function ColorScale(F, B: TColor32): TColor32; The functions in the JCL were copied from Graphics32. Use the one in Graphics32 instead. Yes I do. I've been working on getting it ready for release and integration into Graphics32 for several years. The dithering works fine but I'm not satisfied with the quality of the accompanying Octree quantizer I've implemented so it has all been postponed until I have implemented something better. FWIW, I'm not using any of the above color distance functions since the color mapping is implicit with the Octree algorithm (the one I'm using anyway). I'm also not quantizing and dithering in sRGB color space (sRGB is what you'd normally just call RGB). Instead I'm either using the Linear RGB (gamma corrected RGB) or OKlab color spaces. OKlab appears to be the best there is right now for perceptual color mapping and distance. If your quality requirements aren't too strict you can just use my old quantizer (also Octree) and dithering routines in the GifImg unit: https://docwiki.embarcadero.com/Libraries/Sydney/en/Vcl.Imaging.GIFImg.ReduceColors

Ah, yes I see your point. Interesting. A bit labor intensive though, having to vet all the different solutions. Personally, I use another approach 🙂

Ouch! I use that a lot. 9182 occurrences in the project I'm working on right now. I guess that just aborted our migration to Delphi 12 - again.

Do you really want your code to be generated based on fuzzy statistics? How do you even verify the correctness of the results? I'd like mine to be based on strict patterns and known deterministic properties of those patterns. I think trying to solve these problems with AI is a bit like when some companies moves their stuff to the cloud; They don't understand how it works or know what is going on but now it's somebody else's problem.

I have it and many of the techniques in it that were great 10-15 years ago are totally unnecessary today and even detrimental with modern CPUs. It's still a good read and even though some techniques are obsolete, knowing them can help solving other similar problems simply because they can make you think about problems differently. Um... Always? There used to be a time, not that long ago, when integer math was far superior to floating point math (see: Hackers Delight). Not so anymore. via https://stackoverflow.com/questions/2550281/floating-point-vs-integer-calculations-on-modern-hardware The video is a bit long so I haven't watched it yet, but it's LEA: Load Effective Address, "LEAL" is AT&T syntax for LEA (Intel syntax). Here's a good comment on the topic by Peter Cordes: Using LEA on values that aren't addresses / pointers? Before you start replacing all your shifts with LEA you should be aware that it isn't always faster. As with almost everything in modern CPUs it depends on what the CPU is otherwise busy with. https://stackoverflow.com/questions/70316686/assembly-why-is-lea-eax-eax-eaxconst-shl-eax-eax-const-combined-fast

The ability to at least filter on Components would be nice so one can focus on areas of interest. I don't know if that is possible though... https://jira.atlassian.com/browse/JSDCLOUD-1106 https://jira.atlassian.com/browse/JSDCLOUD-4384 https://jira.atlassian.com/browse/JSDCLOUD-4356 Knowing Atlassian, If it isn't possible then it'll stay that way.

Yes, I did that the third time. I just wish they would remember my choices going from 12.0 to 12.1; It's hardly rocket science...

Again? What was old is new again - except my jokes.

Just answer No to the question "Do you want to remove all RAD Studio 12 entries from your registry?" and you should be fine (depending on your definition of "fine"). The Delphi installer has always been a case study in poor usability. This time it took me 4 tries before I got everything I wanted installed. First time I forgot to change the install location. I do this pretty much every other time. Second time I installed Android platform support but didn't select to also install the (apparently required) JDK. Third time I discovered that since didn't explicitly select to install Windows platform support, I only got the 32-bit compiler.

That's not how you do it. I doubt Remy will have time or motivation to look at whatever it is you have done. Fork the original repository. Make a branch. Apply your changes. Create a pull request to have your changes merged into the original repository. 2-4 should be done once per separate issue. A single issue that makes 20 unrelated changes probably has zero chance of being accepted.

That would have had zero impact on their self-hosted Jira since its support expired 7 years ago anyway. I'm not saying I don't understand why they would want to migrate to something else, but the reason you state ain't it.

The new Atlassian slogan

Yes, I fear it will. While I haven't used it yet and there's presently nothing there, I'm really afraid this just wiped out yet another small community. Tick tock, tick tock.

aaaaaaaand it sucks. But at least, from reading the announcement, it appears they know it sucks.

You have been able to do that in Delphi for 10-15 years - Just not with both editors docked.