anonmiraj / fig Goto Github PK
View Code? Open in Web Editor NEWFIG (Fortran Intuitive Graphics)
License: MIT License
FIG (Fortran Intuitive Graphics)
License: MIT License
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 last two backends can use the algorithms from this library.
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.
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
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
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.
Feel free to contribute to any of the mentioned tasks or propose other file formats.
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.
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
Let's extend the color definition by implementing a type(color)
class for color handling
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
Consider, instead of implementing your own, to use an external library:
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
List of miscellaneous improvements that I'm seeing on the current repository
pure elemental
functions:Lines 15 to 23 in 36c15fa
Lines 25 to 32 in 36c15fa
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)
i0
format to avoid spaces when printing integers:Line 41 in 36c15fa
Lines 5 to 11 in 36c15fa
type(mytype)
...
contains
procedure, non_overridable :: to_int => rgb_to_int
end type
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
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
Here is a list of the primitives that I plan to support. Items marked with "?" are aspects I am still unsure how to implement:
All primitives should support attributes like stroke size, stroke color, and fill color.
Anti-aliasing should be enabled by default.
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
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.