Colors

[perazz]

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

https://github.com/AnonMiraj/fig/blob/bb22678d454eb132b425d3af195b243702adbdf2/src/backends/vector/svg_backend.f90#L9

• [x] define an internal representation (rgbw? alpha? etc.)
• [x] export color to/from HTML/CSS format, first of all to be suitable for svg
• [x] 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

• [x] 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

[johandweber]

Here some thoughts about the color depth

8 bit per color

[+] Saves memory space [+] Completely sufficient for "output-only" tasks displaying things on the screen, preparing plots for a publication ... [+] The "natural" color depth of the web (HTML-Colors, JPG, many traditional widget toolkits). Therefore (appart from possible bit shifts) no math is required to convert the internal representation [-] Many general of scientific image formats (TIFF, Camera RAW Data, FITS) support, at least optionally, a higher bit depth. Therefore data from these file Formats can not be processed without losing data. [-]- For scientific image processing 255 possible values per channel may be insufficient concerning the precision and/or the dynamic range

more than 8 bit (16 bit, 32 bit, floating point)

[+] Image data with more than 8 bit can be processed without information [+] Converting down to 8 bits is still possible [-] ... however transformations are required, so there is some performance penalty and additional coding to do [-] The memory footprint is larger.

So I think the color depth of on the goals of the project, 8-bit is fully sufficient for plotting, but in my opinion not necessaryly for image manipulation.

Another Question RGB values are a typical example of the use of unsigned integers,l which are not supported by Fortran.

There are several ways around like

• Using a larger internal value range that is is used for the input and output (and the bit shifts)
• Using some conversion routines like in my Fortran wrapper around the GD lib . I am not sure about that.

[johandweber]

I have now created a pull request including a module containg the CSS/SVG colors as constants.

While I assume that this will have to be changed, it might be a first step.

[perazz]

unsigned integers,l which are not supported by Fortran.

I think an easy solution that doesn't affect memory storage much would be to use 16-bit integers, but then of course only support the 0-255 range. Another option is to use an unsigned integer implementation like https://github.com/ShinobuAmasaki/uint-fortran

[johandweber]

unsigned integers,l which are not supported by Fortran.

I think an easy solution that doesn't affect memory storage much would be to use 16-bit integers, but then of course only support the 0-255 range. Another option is to use an unsigned integer implementation like https://github.com/ShinobuAmasaki/uint-fortran

I have also implemented a small collection of functions that take a can take a value from a "larger" integer value and convert it into a "smaller" Fortran integer whose bit pattern corresponds to an unsigned value of the same size. It assumes that the data types follows twos' complement, which as far as I understand is the case for all modern CPUs.

https://github.com/johandweber/funsignedwrapper/tree/main

Unfortunately my solution is rather slow.

In contrast to the solution presented above it does not really support unsigned inter math, but is aimed at just generating the correct bit pattern (mainly for exchange with C libraries).

[johandweber]

Having thought about it, I think that for the current stage the mapping of the colors is handled well in fig_rgb.f90. Maybe I have been overemphasizing that topic because I think a bit too much in categories relevant for image processing. Futhermore I noticed that the algorithms for the primitives are in principle independent of the color representation, so changing the used color model would not really be very detrimental to the project.

[AnonMiraj]

I think this settles it for this issue. If there is something I missed, feel free to open the issue. There is still a lot of talk about handling depth and other stuff, but I think it is better to focus on them later.