What is the future roadmap of Graphics32 ?

[Rollo62 536]

@Anders Melander

I recently saw this post from you, as a maintainer of the wonderful Graphics32 libary.

https://en.delphipraxis.net/topic/4140-smooth-scaling-of-bitmaps/?do=findComment&comment=36266

So I hope that you and/or others might have more insights about the future of the Graphics32 project.

I used it in the past very successfully, and would also nowadays bet on it, but the activity of this project is quite slow.

Why is that, I cannot really understand ?

 

I have seen attempts from ZhaoyiPeng, to bring Gr32 to FMX, but also this moves quite slow, or is stalled.

I see effords from Angus Johnson, to push a new Image32 project.

 

Is the Image32 based partly on Graphics32 technologie ( I'm afraid its not), or how does it fit all together ?

I had no time to look into all that more deeply, but the Gr32 for FMX seems to be only a proof of concept,
and many features still missing.

 

My original though was that Gr32 is able to use different backends, so it might be possible to port this to FMX too.

Since FMX makes use of GPU, I'm not really sure if Gr32 can beat this, but
I think Gr32, on the other hand, has features that were not available in FMX right now, and still would make sense.

 

Anyhow, beside FMX, for VCL this seems to be still the great choice for bitmap operations.

So what is the status and the roadmap of this project ?

Would be good to know.

Is this lack of maintainers or lack of interested users ?

 

 

 

 

Edited January 7, 2021 by Rollo62

[Edwin Yip 154]

FYI: I've asked Angus Johnson the author of Image32 the why he started Image32 instead of contributing to Graphics32, he pointed me to a public page which had the answer (but no longer exist): he had been contributed to GR32 for many years, and later concluded thta since the code base of GR32 is huge and he'd move faster by starting everything new.

[Oberon82 1]

What kind of differencies are between GR32 and Image32?

[Edwin Yip 154]

2 hours ago, Oberon82 said:

What kind of differencies are between GR32 and Image32?

I haven't checked Image32 in depth, but I compiled and run all the demos and glimpsed the documents, here is my incomplete initial feeling:

• While not as feature-rich as gr32, Image32 already includes a solid foundation for imaging viewing/blending/manipulation, polygon drawing, text drawing, and so on.
• IIRC one of the demo which allows mouse drag-and-drop to resize/change perspective and it's more responsive than a demo of gr32 (note, this doesn't imply it's slower for faster, but just a memory of mine...)
• I want more layer features from Image32...

 

Just FYI.

Edited January 7, 2021 by Edwin Yip

[Rollo62 536]

5 hours ago, Edwin Yip said:

... concluded thta since the code base of GR32 is huge and he'd move faster by starting everything new.

Thanks, thats a fair goal, but wouldn't it have been better to start with a cleaned up GR32 branch then ?

Maybe sometthing like Gr32 V2.0 (or 3.0) is still possible.

 

Quote

Just FYI.

So you would recommend Image32 over Graphics32 for new projects ?

But at the moment I think its Angus project alone, and not sharing some parts with the community.

That can be good to have a tough leader, avoid smearing out the core philosophies, but its also some kind of risk.

 

 

Edited January 7, 2021 by Rollo62

[Edwin Yip 154]

38 minutes ago, Rollo62 said:

Thanks, thats a fair goal, but wouldn't it have been better to start with a cleaned up GR32 branch then ?

It's Angus's decision and he can do whatever he wants...Although I also wished he continued with gr32...

 

Quote

So you would recommend Image32 over Graphics32 for new projects ?

No, I didn't, you must evaluate them and make the choice...

Quote

But at the moment I think its Angus project alone, and not sharing some parts with the community.

sourceforge.net is a collaboration platform and anybody can contribute.

Quote

That can be good to have a tough leader, avoid smearing out the core philosophies, but its also some kind of risk.

I know nothing about if Angus is tough or not :D

[Anders Melander 1783]

The Graphics32 team

First of all I'm not the maintainer of Graphics32. I'm just a contributor. I don't even have admin rights to the main repository.

As far as I'm concerned the current project lead is @CWBudde1 but I'm not sure he agrees and he's also been largely absent in a long time. Of the remaining 4 members, micha137 hasn't contributed anything significant in a year and Michael Hansen, Mattias Andersson and Andre Beckedorf hasn't been active in a decade.
https://github.com/graphics32/graphics32/graphs/contributors (I'm not sure how reliable that page is as I seem to be absent from it).

 

Roadmap

The last roadmap I know of was from 2012 (posted in the old graphics32 newsgroups) and concerned the "mythical version 2.0". Since then some of the items on the roadmap has been implemented, some has been superseded and some things not on the roadmap has been added.

At present only the Graphics32 issue tracker at Github gives any indication of the direction the project might move.

 

Lack of progress

From my POW the inability to make a decision and actually release version 2.0, incomplete or not, has been one of the reasons why the project has stalled. For example the present version supports Delphi 7 and later which greatly limits what can be done - or what people are willing to do. A new version would drop support for ancient versions of Delphi and only support XE and later. In April 2019 it was decided, by Christian, Angus and I as far as I recall, that we should just release version 2.0 as-is. But again, without anyone to take the lead, nothing happened.

 

In my opinion the greatest blow to Graphics32 was the complete loss of the Graphics32 community. This happened when the project was moved to Github and people stopped using the newsgroups. Github is great for managing the project but it's not a community platform. Without a community we're left with individual developers that might still have an interest in the project itself but soon burns out or simply isn't interested in developing in a void with no interaction with others or feedback from the users.

Apart from the discussions and QAs, a big part of the old newsgroups was that people posted examples of what they did with Graphics32 and how they did it, extension libraries and graphic algorithm implementations. Luckily I still have an almost complete local copy of the newsgroups and it's still a great resource for inspiration, examples and solutions.
Actually it seems the usenet server is still alive: nntp://news.graphics32.org Of course one needs a news client to access them and I'm probably one of the last people on earth to have one installed

 

Image32

I have read the Image32 documentation and I think I've looked at the source once but beyond that I have little knowledge about the project.

I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess.

As far as I can see the "architecture" of Image32 is that there isn't one; While Graphics32 is an object oriented framework on top of some highly optimized low level routines, Image32 is more of a monolithic design - one class does everything. As far as I remember this dislike of OO was one of the reasons he wanted to write his own. Another was that he felt Graphics32 had become bloated. I don't agree but that's beside the point.

 

Current state of the project

As I see it the current version (i.e. head in the master branch) is stable. There are no grave issues and nothing technical that hinders future adoption of the library into new projects.

The documentation has fallen behind and in a few places it is no longer correct.

The examples aren't that great but at least they compile and do what they were written to do.

 

The future

As I'm just another contributor I can only speak to what I would like to see happen.

• Someone has to take the lead. It could be me but then I would have to stop contributing code. I can't do both. Also, although I do have opinions about how and what should be done my area of expertise is architecture and implementation.
• Get 2.0 released or simply abandon the idea of major release versions. As I said above before the 2.0 problem is resolved there will be little or no progress.
• Move the documentation into a wiki so we're actually able to maintain it. Currently it seems updating the documentation requires custom tools and I for one don't need the hassle of building, installing and maintaining some tool just to keep the docs up to date. It's hard enough to find the motivation to do so without that.
• Separate the examples from the showcases and write some (or a lot) of small, simple examples that demonstrate how to get started with Graphics32 and how to solve the most common tasks/problems. Even I hardly look at the current examples when I need to figure out how to do something as they are mostly too advanced or bury the relevant code in unrelated gimmicks. I can imagine that they must be undecipherable to a new user.
• Get rid of or repair the code contributed by cowboys. Some of the newer features of Graphics32 was contributed (and accepted) without regard for the fact that other people should be able to maintain it (for example if the author went awol or decided to work on another project instead). The code should be commented, the algorithms used should be documented, etc.

Even if none of the above happens I think Graphics32 will be safe for the immediate future. It's a stable and fairly complete library and there are enough people and projects using it that someone else is bound to pick up the mantle if all the current contributors get hit by a bus.

[Edwin Yip 154]

3 hours ago, Anders Melander said:

Actually it seems the usenet server is still alive: nntp://news.graphics32.org Of course one needs a news client to access them and I'm probably one of the last people on earth to have one installed

 

Aside from the insightful info, wow! This is my new year gift. I have been using the gr32 group as the main reference many years ago but somehow I lost the access and my local copy, and somehow the server set in my Thunderbird was wrongly set to gr32.org instead of the correct one - graphics32.org, not sure what happened, maybe there was an domain name change or something like that...

 

Now I'm downloading the 13,000+ threads to my local computer to keep the archive ;)

 

Edited January 7, 2021 by Edwin Yip

[angusj 126]

20 hours ago, Rollo62 said:

Thanks, thats a fair goal, but wouldn't it have been better to start with a cleaned up GR32 branch then ?

 

That was indeed my initial intention. However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR).

 

19 hours ago, Anders Melander said:

Image32

Image32 is more of a monolithic design - one class does everything.

I'd disagree with Anders on that, though of course I could still greatly improve Image32's design.

 

It's fair to say the TImage32 class that's at the core of my Image32 library does have a large number of methods related to loading and saving images, as well as a number of image manipulation methods (including hue adjustment and basic afine transformations - scale, rotate etc). But most of these methods (or similar) also appear in Graphic32's TBitmap32 class. IMHO Graphic32's TBitmap32 is much more monolithic, as it containing a whole host of line rendering methods (as mentioned above) and text (polygon) rendering methods too. These really shouldn't be there, as these operations are much better served by the functions found in Graphic32's Gr32_VPR unit. Further, TBitmap32's line rendering methods will only draw 1 pixel wide lines which is extremely limiting. So I would argue that my TImage32 class is much less monolithic than the TBitmap32 class.

 

19 hours ago, Anders Melander said:

I would be very surprised if Angus didn't use the techniques used in Graphics32 as inspiration. Although I know he loves to write things from scratch I doubt that he doesn't use Graphics32 as a reference. Anyway, I can only guess.

Almost none of my Image32 libray uses code from Graphics32. The excepion to that is a small amount of code in my Image32_Draw unit where the polygon renderer uses a memory allocation technique I copied from Mattias Andersson's Gr32_VPR unit. (When comparing Image32 rendering performance with Graphics32, I couldn't figure out how Mattias' rendering was so efficient.) Nevertheless my polygon renderer is based on https://nothings.org/gamedev/rasterize , though it still isn't quite as fast as Mattias' renderer. I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution).

 

 

With regard to which library is better, I suggest if you're familiar with Graphics32, or if polygon rendering performance is critical, then use Graphics32. However, Image32 does offer several benefits over Graphics32. It's a much simpler library to learn and use IMHO and it contains better cross-platform support with both Lazarus and FMX options.

 

 

Edited January 8, 2021 by angusj

[Edwin Yip 154]

@angusj, thanks for the very informative reply! 

 

Can somehow Image32/Graphics32 work together, for someone who mainly uses gr32 but needed a feature from Image32 but missing from gr32?  If not, do you have such a plan in the future?

[Anders Melander 1783]

Hi Angus and welcome

25 minutes ago, angusj said:

However, the more I tried to remove what I considered obsolete code, the more problems I encountered as I found what seemed obsolete was still used by other parts of the library. For example TCustomBitmap32 has 14 different Line methods, 7 LineTo methods, 7 HorzLine methods and 7 VertLine methods. That really is excessive and IMHO should be removed and intead use the separate and much more flexible polygon renderer (in GR32_VPR).

Well, if all you want is a hammer then all the other tools may indeed seem like bloat.

 

The VPR polygon renderer and the line methods solve two different but similar problems. Remember that the purpose of Graphics32 is to do things as fast as possible. This means specialization over generalization.

VPR is a generalized vector renderer that does many things reasonably well while the line methods does one single thing as fast as possible. That's why, instead of a single line method with a bunch of parameters, we have individual methods for vertical lines, horizontal lines and "other" lines. It's also why each of these methods are found in different variants each supporting different feature combinations: clipped or unclipped coordinates, transparency, anti alias or not, patterns, etc. And for different numeric types: integer, floating point or fixed precision.

It's all about avoiding compromises that would hurt performance and give the user of Graphics32 control over the choices that have an impact on performance. Replacing the line methods with VPR would be like putting all-weather tires on a Formula 1 car.

 

The MoveTo/LineTo methods, like their TCanvas counterparts, are purely high level convenience methods that will be superseded and can be removed once the TCanvas32 rewrite gets merged. But that's being blocked by the 2.0 non-release

 

1 hour ago, angusj said:

I did also briefly copy Projective Transform code from the Graphics32 library (with attribution), but that was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution).

Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one.

[Anders Melander 1783]

57 minutes ago, Edwin Yip said:

Can somehow Image32/Graphics32 work together, for someone who mainly uses gr32 but needed a feature from Image32 but missing from gr32?

If the internal pixel data format is the same (which I suspect they are), then you can wrap a TImage32 in a TBitmap32 via a Graphics32 memory backend. They will both be operating on the same block of pixel memory so take care if you resize the TImage32 while the TBitmap32 is associated with it.

 

I don't think you can do it the other way round (wrap TBitmap32 in a TImage32) since TImage32 doesn't have a backend concept.

 

Of course you can always copy the pixel data from one to the other, manipulate it and then copy it back, but that's not very efficient.

[Edwin Yip 154]

58 minutes ago, Anders Melander said:

Remember that the purpose of Graphics32 is to do things as fast as possible. This means specialization over generalization

And I greatly appreciate that!

[Anders Melander 1783]

6 hours ago, Anders Melander said:

 

8 hours ago, angusj said:

[the] Projective Transform [...] was replaced some time ago with my own code adapted from some more flexible JavaScript code I found here https://math.stackexchange.com/a/339033/384709 (again with attribution).

Interesting. It looks like it should be easy to adapt that algorithm to the Graphics32 transformation framework. I'll give it go and compare it to the existing one.

 

Turns out there's almost nothing gained from using that method. While the matrix setup (which runs only once) is slightly faster, the transformation matrix (which is used once per target pixel) is exactly the same and thus yields the same performance and result.

[c0d3r 17]

Do any of you plan to have your components to support 64-bit in near future?

[Anders Melander 1783]

4 minutes ago, c0d3r said:

Do any of you plan to have your components to support 64-bit in near future?

As far as I know Graphics32 has supported 64-bit for ages. Doesn't it work for you?

[c0d3r 17]

10 minutes ago, Anders Melander said:

As far as I know Graphics32 has supported 64-bit for ages. Doesn't it work for you?

Oh,  Sorry,  I didn't know that.  Thats great!

[angusj 126]

On 1/9/2021 at 7:13 AM, Anders Melander said:

 

Turns out there's almost nothing gained from using that method. While the matrix setup (which runs only once) is slightly faster, the transformation matrix (which is used once per target pixel) is exactly the same and thus yields the same performance and result.

Anders, I didn't claim that the Image32 projective transform algorithm was faster, but that it was more flexible.

Projective transform require a set of 4 source coordinates and a set of 4 destination coordinates indicating source and destination quadrilaterals.

While both algorithms obviously require the user to specify the destination quadrilateral, the Graphics32 algorithm simply uses the source image bounds as the source quadrilateral, whereas the Image32 algorithm allows the user to define a source quadrilateral too (which can be very useful).

 

19 hours ago, c0d3r said:

Do any of you plan to have your components to support 64-bit in near future?

Both libraries support 64bit compiling. However, if you're referring to 64bpp (bits per pixel) images then neither library support this. Both libraries load and manipulate images using 32 bpp (hence the 32 in their names 😁), though images can still be saved to file using lower color resolutions.

 

On 1/8/2021 at 9:49 PM, Anders Melander said:

It's all about avoiding compromises that would hurt performance

But too many options just makes a library unhelpfully complicated for the average user.

 

Edited January 10, 2021 by angusj
grammar & clarification

[Anders Melander 1783]

15 hours ago, angusj said:

Anders, I never claimed that the Image32 projective transform algorithm is faster

Yes, that was my assumption.

 

15 hours ago, angusj said:

While both algorithms obviously require the user to specify the destination quadrilateral, the Graphics32 algorithm simply uses the source image bounds as the source quadrilateral, whereas the Image32 algorithm allows the user to define a source quadrilateral too (which can be very useful).

You can use the Graphics32 to map from a quadrilateral to a rectangle too (for example I use it for perspective correction), but it's true that one of the quadrilaterals must be a rectangle.

 

However since it can do both forward and reverse transformation you can actually use two of them to do quadrilateral to quadrilateral transformation although that would not be very efficient. A better way would be to use one to create the source matrix, use a second to create the destination matrix, multiply the first with the inverse of the second and use the result as the transformation matrix. I believe that's also the method you use. I.e. Matrix = SrcMatrix * Adjoint(DstMatrix)

 

15 hours ago, angusj said:

too many options just makes a library unhelpfully complicated for the average user.

True, but I don't think Graphics32 has ever targeted the average user. It does have a steep learning curve and does require an understanding of at least some of the low level principles - such as alpha compositing.

[Edwin Yip 154]

22 minutes ago, Anders Melander said:

9 minutes ago, Anders Melander said:

True, but I don't think Graphics32 has ever targeted the average user. It does have a steep learning curve and does require an understanding of at least some of the low level principles - such as alpha compositing.

@Anders Melander,

I agree, and I appreciate the versatility , flexibility and performance provided by gr32!

In addition to the alpha compositing link, would you list other low level principles required to better use GR32?

Thanks!

 

[Anders Melander 1783]

On 1/10/2021 at 6:42 PM, Edwin Yip said:

In addition to the alpha compositing link, would you list other low level principles required to better use GR32?

Hmm. I can't really say. I guess it greatly depends on what you're doing.

FWIW, the alpha composition part is actually documented in the help. One of the things people often struggle with is the difference between blend, merge and combine and in which situations to use what. Even I get them mixed up at occasionally.

If performance is critical then it would be good to know about the different data types: TFloat, TFixed and integer. I think everybody understands float and integer but I guess fixed precision math isn't common knowledge. The graphics32 TFixed is a 32-bit binary with 16 magnitude bits and 16 fractional bits. I don't have any good links at hand. Google "fixed point".

[Edwin Yip 154]

Thanks! Yes, Blend, Merge and Combine, these are the most confusing part!

[angusj 126]

4 hours ago, Anders Melander said:

One of the things people often struggle with is the difference between blend, merge and combine and in which situations to use what.

And adding to that confusion is TDrawMode and TCombineMode.