anonmiraj / fig

FIG (Fortran Intuitive Graphics)

FIG (Fortran Intuitive Graphics)

FIG is a Fortran library for that aims to provide intuitive graphics capabilities. Currently It offers basic 2D primitives such as lines, circles, ellipsis, triangles, and rectangles for creating graphical representations within Fortran programs.

Gallery:

Below are some examples of images created using FIG:

you can generate them yourself using fpm test

fig's Issues

Coordinate space design

This issue wants to support the discussion of how to design a unique coordinate space @AnonMiraj @johandweber @everythingfunctional.

One option could be to have one class that describes coordinates in the drawing space:

type :: point
   real :: x
   real :: y
end type point

All (x,y) coordinates in the drawing space that appear on the canvas would be of type(point) and in range between point(0,0) and point(1,1).

The canvas would instead be described by image coordinates (pixels):

type :: canvas_point
   integer(pixel) :: x
   integer(pixel) :: y
end type canvas_point

type :: canvas_size
   integer(pixel) :: width
   integer(pixel) :: height
end type

A type(canvas_size) :: size variable would be included in every canvas.

A linear mapping can describe the relationship between point and canvas_point: something like

elemental type(canvas_point) function to_canvas(x, size) result(pxl)
   type(point), intent(in) :: x
   type(canvas_size), intent(in) :: size

   pxl%x = nint(x%x*size%width, kind=pixel)
   pxl%y = nint(x%y*size%height, kind=pixel)
end function

Colors

Let's extend the color definition by implementing a type(color) class for color handling

fig/src/backends/vector/svg_backend.f90

Line 9 in bb22678

character(len=:), allocatable :: fill_color

• define an internal representation (rgbw? alpha? etc.)
• export color to/from HTML/CSS format, first of all to be suitable for svg
• define parameter or initializer-based colors:

option 1
type(color), parameter :: BLACK = color(r=0,g=0,b=0)

option 2

!name-based initializer
interface color
   module procedure named_color
end interface color

type(color) function named_color(name)
   character(*), intent(in) :: name
   select case (name)
      case ('black')
          ! .... etc
   end select
end function named_color

• define a background for the whole canvas (whether SVG or not): for now, flat color [with transparency]

Consider, instead of implementing your own, to use an external library:

• https://github.com/vmagnin/forcolormap

cc: @johandweber @everythingfunctional

Handling optional properties of shapes

Currently, when properties like 'stroke_color' are omitted in shapes, the code behaves unexpectedly by using a random value. This behavior is undesirable. We need a better approach to handle optional properties like 'stroke_color.'

I have two ideas in mind:

• Using Default Values: Instead of relying on random values, we can set default values for optional properties like 'stroke_color.' If a property is not explicitly set, it defaults to a specific value (e.g., transparent or a predefined color).

• Using Pair Structure: We can create a pair structure for each optional property. This structure would include the property itself and a logical flag indicating whether it has been set.

While the first one is easy and straightforward, it will involve a lot of unnecessary operations and will bloat the resulting SVG.

The second one would work better, but I feel like it is not a very clean approach.

I would like your opinion on how to handle them.

support for image file drivers

So far, the library only supports writing to PPM.
I plan to add support for other popular image formats. The initial target formats are BMP, PNG, and GIF, with consideration for additional formats in the future.

• add support for read from PPM.(@johandweber )
• BMP.
• GIF.
• PNG.

Feel free to contribute to any of the mentioned tasks or propose other file formats.

Create `drawing` class

cc #12 (comment)

Separate the drawing primitives from the canvas by creating a new type(drawing) class:

   type:: drawing 
         real :: width, height
         character(len=:), allocatable :: title
         type(shapeWrapper), allocatable :: shapes(:)
         integer :: shape_count
     contains
         procedure :: add_shape
         procedure :: init
     end type drawing

Miscellaneous

List of miscellaneous improvements that I'm seeing on the current repository

• wherever possible, define pure elemental functions:

fig/src/fig_rgb.f90

Lines 15 to 23 in 36c15fa

	function rgb_to_int(color) result(rgb_int)
	type(RGB), intent(in) :: color
	integer(pixel) :: rgb_int
	rgb_int = ior(ishft(color%a, rgb_bit_depth*3),&
	ior(ishft(color%b, rgb_bit_depth*2),&
	ior(ishft(color%g, rgb_bit_depth), color%r)))
	end function rgb_to_int

• Functions that are type initializers should go in an initializer interface:

fig/src/fig_rgb.f90

Lines 25 to 32 in 36c15fa

	function int_to_rgb(rgb_int) result(color)
	type(RGB):: color
	integer(pixel), intent(in):: rgb_int
	color%a = ibits(rgb_int, 3*rgb_bit_depth, rgb_bit_depth)
	color%b = ibits(rgb_int, 2*rgb_bit_depth, rgb_bit_depth)
	color%g = ibits(rgb_int, rgb_bit_depth , rgb_bit_depth)
	color%r = ibits(rgb_int, 0, rgb_bit_depth)
	end function int_to_rgb

i.e. something like

interface RGB
   module procedure int_to_rgb
end interface

! So you can define your RGBs as 
my_color = RGB(pixel_int)

• Use i0 format to avoid spaces when printing integers:

fig/src/fig_rgb.f90

Line 41 in 36c15fa

write(color_string, '(A,I3,A,I3,A,I3,A,F5.3,A)') 'rgba(', color%r, ',', color%g, ',', color%b, ',', alpha, ')'

• Put class functions inside the derived type:
  

  fig/src/fig_rgb.f90

  Lines 5 to 11 in 36c15fa

  	type :: RGB
  	sequence
  	integer(rgb_level) :: r
  	integer(rgb_level) :: g
  	integer(rgb_level) :: b
  	integer(rgb_level) :: a
  	end type RGB

type(mytype)
...
contains
   procedure, non_overridable :: to_int => rgb_to_int
end type

cc @everythingfunctional @johandweber

fig_draw_pixel

Hello,

i noted, that the color used in the argument list of fig_draw_pixel is represented by an integer,
whereas the colors of all other drawing operations are of type RGB.

I understand that this is very likely done for performance reasons, and I think the subroutine is well implemented,
but maybe the name of the subroutine should somehow reflect that it treats colors in a different way.

Yours,
Johann

May ForImage utilize FIG features?

Hello,

Thank you for sharing your project.

I have also developed a Fortran library called ForImage for processing and editing PNM images and managing colors, which is used by ForColormap as a dependency. I would like to inquire whether you would be interested in integrating some functionalities from your project into ForImage?

Best regards,
Ali

License

Hallo,

so far your library does not indicate its license.

The license is not only important for the users but also with respect to what code can be used by the licence.

For example, LGPL code can not be copied/adapted into a public domain library.

Furthermore, it may also be relevant for possible contributors.

In case the library is aimed to be the combined work of a group (for example, in the context of GSoC) you should coordinate with the rest of the team. Else the code is your own and you can decide.

Yours,
Johann

Area filling

Hello,

I really like your new triangle examples.

In my opinion it would be useful to add an general area filling subroutine where alk contiguous pixels of the same color are recolorized. This might be useful for irregular shapes, which occur, for example, in geographical maps.

If you think that this makes aense, Iwould like to help and maybe create a pull request within the next week.

Yours,
Johann

Design of a plotting library

It would be interesting to create a plotting library frontend. For that we should learn from Matplotlib, as well as the C++ version of it: https://github.com/alandefreitas/matplotplusplus. We need to figure out some good intermediate representation for vector objects that represent the plot.

For the backends some ideas are:

• the glfw library could be used (it seems it is in conda).
• SVG (pure Fortran, just emit the xml as a string)
• PNG (use a C library to actually save it, or stdlib)
• PPM (use stdlib, pure Fortran)

The last two backends can use the algorithms from this library.

CC @everythingfunctional, @perazz.

Primitives support

Here is a list of the primitives that I plan to support. Items marked with "?" are aspects I am still unsure how to implement:

• Lines
• Rectangle
  • Rounded corners?
• Circles
• Ellipses
• Triangles
• Polygons
• Polylines
• Bézier curves
• Paths? (https://developer.mozilla.org/en-US/docs/Web/SVG/Tutorial/Paths)
• Drawing text

All primitives should support attributes like stroke size, stroke color, and fill color.
Anti-aliasing should be enabled by default.

Segmentation faults

When performing

fpm test

i get segementation faults for the tests circle.90 and rect.f90.

My compiler is gfortran 13.2 ( Linux x64).

Here is a backtrace:

Backtrace for this error:
#0  0x721f48623930 in ???
#1  0x721f48622a95 in ???
#2  0x721f4824298f in ???
        at ./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
#3  0x60664adea9a3 in __fig_canvas_MOD_fig_save_to_ppm_file
        at ././src/fig_canvas.f90:34
#4  0x60664ade354e in circle_test
        at test/circle.f90:1
#5  0x60664ade3663 in main
        at test/circle.f90:2

So it appears to be connected with fig_save_to_ppm_file.

add topic tags

I suggest adding the topics graphics, fortran-package-manager in the About section, as described at https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/customizing-your-repository/classifying-your-repository-with-topics