Anders Melander

Show us what you mean; We still can't read your mind.

• What does it look like?
• What do you want it to look like?

11 hours ago, banaguitar said:

but it's not centered.

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.

37 minutes ago, banaguitar said:

How to adjust the size of the png?

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);

Is it a known problem that the VCL misinterprets the valid range of TScrollBar's PageSize and Max properties?

TScrollBar enforces the rule that PageSize must be <= Max but Windows requires that PageSize be <= Max-Min+1...

This means that if one sets PageSize=Max it is still possible to move the scrollbar +/-1 unit.

One work around seems to be to set Min to 1 - because TScrollBar forgets to take Min into account when validating PageSize 🤦‍♂️

https://learn.microsoft.com/en-us/windows/win32/api/winuser/nf-winuser-setscrollinfo

Quote

The nPage member must specify a value from 0 to nMax - nMin +1.

6 minutes ago, banaguitar said:

Hello, thanks for help. Here is a minimal example.

Okay, but:

7 hours ago, Anders Melander said:

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. 

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,

1. You are not specifying the size/position of the bitmap layer.
2. 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.

57 minutes ago, shineworld said:

W10/W11 can run in low-cost devices as like as Raspberry

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.

7 hours ago, banaguitar said:

the size of the png is wrong

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.

1 hour ago, angusj said:

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.

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):

41 minutes ago, DelphiSpass said:

The function ColorScale() I can not find.

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;

44 minutes ago, DelphiSpass said:

While, the function EMMS, it is the one which I found in JclGraphUtils? 

The functions in the JCL were copied from Graphics32. Use the one in Graphics32 instead.

45 minutes ago, DelphiSpass said:

Besides, you mentioned Dithering, if I may ask, do you have code for dithering

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

1 minute ago, Lars Fosdal said:

That is not what I intended to say.  I was wondering if someone had tried to apply LLM for finding even better patterns for optimization than those that are currently implemented.

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

Personally, I use another approach 🙂

42 minutes ago, Uwe Raabe said:

Could be related to String with non-ASCII characters directly attached to a #xx or #$xx literal corrupts the final string

Current workaround is to use a + operator to concatenate the parts.

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.

42 minutes ago, Lars Fosdal said:

I wonder if anyone has tried to train an LLM on Assembly code generation to see if it could improve the current optimization patterns?

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.

1 hour ago, Dalija Prasnikar said:

I have no idea what is in that book, but I doubt that it is very much obsolete.

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.

2 hours ago, Dalija Prasnikar said:

Nor the fact that some operations will always be more expensive than others, no matter the CPU.

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

3 hours ago, Tommi Prami said:

Apparently LAEL ("address calculator") can do multiply by 2, 4 and 8 very fast. 

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

1 hour ago, Lars Fosdal said:

the search is quite rudimentary, compared to the full Jira UI

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.

2 minutes ago, Brian Evans said:

In Delphi 12 you can do Tools -> Manage Features

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...

4 hours ago, Rick_Delphi said:

Now with no-code low-code being new buzzwords

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.

1. Fork the original repository.
2. Make a branch.
3. Apply your changes.
4. 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.

5 hours ago, dummzeuch said:

No. The point was that Atlassian has discontinued supporting on-premise servers

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.

30 minutes ago, Lars Fosdal said:

it beats no system.

The new Atlassian slogan

4 minutes ago, Brian Evans said:

Removes any collaboration between users.

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.