support for image file drivers

[AnonMiraj]

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.

[johandweber]

There my thoughts.

• I think a driver for adding data input would be great.

• The definition of BMP can be found on https://en.wikipedia.org/wiki/BMP_file_format.

• While PNG very wide used, it is a more complex than BMP. So if you really intend to implement it in pure Fortran you should in a first step restrict yourself to a subset. Alternatively, on could use the C reference implementations (libpng, ...) as wrappers. The drawbacks are that the code is no longer pure Fortran and that the licensen (e.g. BSD) may not be compatible with MIT. I am not an international lawyer, so I don't know wheter this has implications for the source code, but it would for the binary code.)
  A pure Fortran implementation is of course possible, but I think it is considerable work

• I think that it is important to keep the drawing part (what happens on the canvas) to be seperated from the input/output part

• One should add a functionallity to read the image data from standard input/output or via pipes, which enables image (or video editing the "UNIX style" and stay flexible
  https://batchloaf.wordpress.com/2017/02/12/a-simple-way-to-read-and-write-audio-and-video-files-in-c-using-ffmpeg-part-2-video/

I have written wrappers for the pipe functionality in my GDlib wrapper and I am willing to help here when I have time
(not so sure whether I have time for a pure Fortran implementation of file format support ...).

[johandweber]

If it is OK for you, I'll try to implement the PPM reader subroutine.
(Using your writer subroutine as a template).

Concerning the discussion external dependencies, there is an interesting post on the
Fortran Discourse Page:
https://fortran-lang.discourse.group/t/is-zero-dependency-code-valuable/7836

[AnonMiraj]

If it is OK for you, I'll try to implement the PPM reader subroutine.
(Using your writer subroutine as a template).

Sure, feel free to do it.
Currently, I am in the middle of midterms, so I don't have a lot of time for the library.

Concerning the discussion external dependencies, there is an interesting post on the Fortran Discourse Page:

I'm really still hesitant about external dependencies.

I was thinking, maybe for PNG, since implementing it all from scratch will be a lot of pain, I will use a deflating library to help. I found two options:

1. Someone already made a binding for zlib in Fortran: Fortran bindings for zlib.
2. I also found this interesting library, libdeflate. It also uses the MIT license (I don't know a lot about how to deal with external dependencies with a different license, so I want to keep it simple). I could make bindings for the library and use these bindings directly.

But still, I would like to at least try doing it all from scratch first. That's why I will leave PNG support for last.

[johandweber]

OK,

I wish you a lot of success for your midterms!

I will also get quiet in the next few weeks
(The next weeks will also be rather busy in my job.)

You can still ping me when you want.

Cheers,
Johann

[AnonMiraj]

• I think a driver for adding data input would be great.

Yeah, I intend for the support to be both read and write.

• I think that it is important to keep the drawing part (what happens on the canvas) to be seperated from the input/output part

I agree.

I have written wrappers for the pipe functionality in my GDlib wrapper and I am willing to help here when I have time
(not so sure whether I have time for a pure Fortran implementation of file format support ...).

Whenever you are free, feel free to do it if you want.

I am not experienced with implementing piping, so I will need to do more research in the future if I implement it myself.

thank you.

[AnonMiraj]

I've decided on how I'll implement the image drivers. I'll work on creating Fortran bindings for some of the stb headers (https://github.com/nothings/stb). I'll do this in another repo to make it convenient for anyone who might need it standalone. Then, I'll depend on it here so that fig supports BMP and PNG formats.

[johandweber]

I did not know about these libraries. They are really interesting (and compatible to the MIT license).

Still, I think we should keep the PPM support in the core library.

[AnonMiraj]

i agree,
i do not intend to stop supporting PPM.
and for Gifs i will probably still implement it in pure Fortran.

[johandweber]

I think now stabilizing the structure of the library has priority, so I do not think I will create pull requests concerning the file input/output until a somewhat stable state has been reached.

[johandweber]

I am wondering how the drivers for the bitmap canvas should be implemented.

• As methods of the canvas objects.
  ==> easier to use, looks cleaner
• As separate functions that take the bitmap canvas as arguments.
  ==> more flexible

Of course, these approaches are not mutably exclusive.

[AnonMiraj]

I was thinking of keeping them as methods of the canvas. I can't see how separate functions would be beneficial in the current design.