Re: [GD-DEVEL] Road to 3.0

Hi Ehtan,

Long time too!

On Sun, Jul 18, 2021 at 5:07 AM Ethan A Merritt <[email protected]> wrote:

> 10-15 years ago libgd was a mainstay for scripted output from gnuplot.
> Since then it has lost ground to cairographics for scripted use and to
> Qt or wxWidgets for interactive use.   Nevertheless there are still a lot
> of people choosing libgd for various reasons, and I think an upgrade to the
> capabilities would be very welcome.

thank you :)


> 1)  By far the most requested feature is control over dot/dash patterns.
> Since gnuplot is a plotting program, this means the pattern must be
> continued along a path drawn in many segments.  Furthermore the
> implementation must support arbitrary line widths.
> Neither I nor other gnuplot developers have managed to find a way to do
> this acceptably using libgd in the past (that doesn't mean it's impossible,
> but our past attempts have all failed).

It is basically impossible right now but for a single shape, somehow.
And only for non wide lines based shapes.

Correct dashed path is challenging but not hard per se. I think libgd
now has the base to implement it like path divisions/flattening,
(including cubics or quads). There is a basic dash implementation but
it is not good.

I would be very happy to work closely with the gnuplot teams to
provide out of the box dash implementations. For the record, the ideal
target would be something like:

https://hal.inria.fr/file/index/docid/907326/filename/paper.pdf

Also, I do like to keep the implementation as close (if not 100%) as
possible with Canvas and Cairo which is a kind of standard already. It
does not mean we cannot add more advanced features on top as well
(like the pattern dash describe in the paper above, a path used as
dashes).

What do you think? Happy also to do a zoom call or chat to have more
details about gnuplot needs.

The main goal for now is to get a friendly and feature complete APIs
for the 2D drawing APIs. Once it is place, I would like to do the
following:

- Tightly integrate Freetype stroker and raster to libgd (now we have
2 steps, gd Paths > FT Stroker > FT Raster), to Paths > Stroker >
direct render (when possible).
- Add support for the smooth Stroker/Raster (LCD and co rendering)
- Add SIMD/SSE2+ support

> 2) Some users are in fields where "image" files are used to store intensity
> data at greater than 8bit per pixel resolution.   In particular I've seen
> multiple requests for support of data input as a 16-bit grayscale PNG file.
> This works already in the sense that you can inspect the image visually
> at lower resolution, as libgd converts the 16-bit single channel input into
> 8-bit per channel RGB.  However the original 16-bit resolution is lost,
> so you cannot proceed to calculating histograms or contours using
> the full resolution of the data.
>
> Primary request:
>   input 16-bit intensity PNG data with the full 16 bit resolution preserved.
> Bonuses for:
>   - support of filter operations (e.g. gamma, thresholding) when converting
>     on demand to 8-bit RGB
>   - output of modified data

That is possible and I think it is needed (I have a few IOT/edge
developers asking for it as well). While I am focusing on ARGB32 and
A8 for now, contributions to add support for 16/24/32 bits are
welcome. PNG supports it as well as other formats. Also, help and
contribs welcome!

> 3) This one is at the thinking-as-I-type stage.
> One use of libgd from gnuplot that has emerged only recently is
> interactive display of sixel images created in libgd and filtered
> through code based on the sixel routines here
>         https://github.com/saitoha/sixel
> for display to the linux console or terminal emulation environments.
> E.g. you ssh tunnel from an xterm to a remote server instance with
> no intrinsic graphics support; gnuplot running on the remote machine
> can send back sixel graphics displayed in-line in the xterm.
> This works already, but I imagine it would be more flexible if the
> bitmap-to-sixel stage were incorporated directly into libgd.
> Sixel allows you to update in place within the terminal window,
> so perhaps it could even be extended to allow the equivalent of
> mouse interaction via arrow keys or other hot-key definitions.
> I'd be happy to help flesh out this suggestion.


Interestingly enough, I could finally start with the 2D API because of
something similar. I need it for printing. While the end format is
different, it is a very similar concept.

best,
-- 
Pierre

@pierrejoye | http://www.libgd.org