hello !
i intend to apply to the Fortran Graphics Library
I’ve drafted a proposal and would appreciate feedback to ensure it aligns with the interests of the Fortran community.
and to improve on it further
i have also coded a small library to make basic graphics and writes it to ppm
the repo
and Thank you .
Hello @ezz ,
I am impressed by your initial work and really like your example images.
Your approach is to create the graphics primitives onto a canvas represented by an array using pure fortran code. On the one hand it feels mote like genuine Fortran than wrapping a C library for drawing. I think this approach is also very flexible with respect to the use of bitmap output with a core library that does not depend on thrid-party libraries.
On the other hand, i guess that more complex drawing operations like drawing text or rotationg require a lot of coding work (or adding dependencies for these primitves).
Not that several of the members of the forum have already written wrappers around several graphics libs such as SDL, RayLib, GD or Cairo Graphics.
While I will not supervise the (possible) project I really like the idea and like to contribute.
Cheers,
Johann
I have now already forked your repository.
Hello,
Any reason why you are using a 1D array to represent the pixels of a 2D plot?
Thank you, I’m glad to have caught your interest.
I’m aiming to minimize external dependencies as much as possible, as that’s practically the main goal behind such library.
and yes drawing text will indeed be challenging, I’m still working on developing a good approach for it.
i guess it is a habit of mine,
and if fortran works like how i imagine, it technically should be a tiny but more efficient.
If my proposal gets accepted, I’ll likely opt for a 2D plot for improved readability.
If you write Fortran code, you have to think the Fortran way 
. Multidimensional arrays are first class (built-in) objects in Fortran, and their use is encouraged whenever they are needed. Using flattened arrays is rarely more efficient anyway (and when it happens, the gain is usually marginal, as you notice).
Antialiasing and support of a modern font library would be particularly desirable. Hershey fonts are particularly useful for 3D and vector-based graphics and easy to implement but their appearance does not typically compare well with modern font capabilities. Are higher-level routines for generating XY plots, contours, … planned or will this be basic graphics operations? The following M_pixel library was specifically for providing a subset of the M_draw/vogle functionality but might still contain some useful ideas. The M_draw library shows how basic wire-frame 3D is not much more complicated to provide than 2D. Something similiar to what you are proposing has been on my list for too long but I never got past
these initial steps so I look forward to seeing your library progress.
The doc gives a better overview of M_pixel: https://urbanjost.github.io/M_pixel/man3.html
One aspect that might be discussed is color depth.
You have chosen 8 bit per color (RGB) which maps the default color depth of most GUIs, of JPG and the HTML color palette and graphics libraries like GD. (The remaining byte in the integer could be used for an alpha channel in the future).
While this is perfect for display purposes, many Image Formats (HEIC, RAW formats, TIFF) are able to store more than 8 bit per color channel, which is useful for image processing. The disadvantage of higher bit depth obviously is the increased memory requirement (and possibly decreased performance).
To achieve higher bit depth, the color channels could in principle be stored both as integer and floating point values.
I do not really have an opinion about what to choose, but I think it is worth thinking about it.
I have no familiarity with the project, but from what I understand, I agree, especially considering that in science some of these image formats are common, and fortran is science/engineering focussed. Being able to handle them might mean people in these fields will be more prone to consider fortran as the go-to language.
i will see what i could manage to do in the gsoc period but this will certainly be in my mind as it is really necessary
sadly this will be outside the scope of ‘fig’
a future library may utilize “fig” to achieve this though
for now basic operations and support for output devices is the main goal
thank you
this will be very helpful
good point
higher bit depth is going to be necessary for scientific computing/processing
True if analysing some real world images, but for such computer graphics higher bit depth is less critical. Maybe for gradient-based shapes if you plan them, but even in this case 8 bits are often enough.
That said, you may think right now about a general design that will make a future 8bits<–>16bits switch easy.