Octave

Summer of Code - Getting Started: Difference between revisions

Page Discussion

Summer of Code - Getting Started (edit)

Revision as of 04:31, 21 January 2021

No change in size ,  21 January 2021
→‎Suggested projects: Move package projects to the end of page.
(→‎Numerical: Flatten category.)
(→‎Suggested projects: Move package projects to the end of page.)
Line 118: Line 118:
* '''Potential mentors'''
* '''Potential mentors'''
: Francesco Faccio, Carlo de Falco, Marco Caliari, Jacopo Corno, Sebastian Schöps
: Francesco Faccio, Carlo de Falco, Marco Caliari, Jacopo Corno, Sebastian Schöps
== Using Python within Octave ==
[[Pythonic]] allows one to call Python functions and interact with Python objects from within Octave .m file code and from the Octave command line interface.  Pythonic may eventually not be a separate package, but rather a core feature of Octave.  This project aims to improve Pythonic with the goal of making the package more stable, maintainable, and full-featured.
Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list].  You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests.  As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?
* '''Mentors'''
: Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others?
== Improve TIFF image support ==
[https://en.wikipedia.org/wiki/TIFF Tag Image File Format (TIFF)] is the de facto standard for scientific images.  Octave uses the [http://www.graphicsmagick.org/ GraphicsMagic] (GM) C++ library to handle [http://www.graphicsmagick.org/formats.html TIFF and many others image formats]. However, GM still has several limitations:
* GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image:
** Building GM with '''high quantum''' means that images of smaller bitdepth will take a lot more memory when reading.
** Building GM with '''low quantum''' will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.
* GM supports unsigned integers only, thus incorrectly reading files such as TIFF with floating-point data.
* GM hides details of the image such as whether the image file is indexed.  This makes it hard to access the real data stored on file.
This project aims to implement better TIFF image support using [https://en.wikipedia.org/wiki/Libtiff libtiff], while leaving GM handle all other image formats.  After writing a [https://octave.org/doc/v6.1.0/classdef-Classes.html classdef] interface to libtiff, improve the Octave functions {{manual|imread}}, {{manual|imwrite}}, and {{manual|imfinfo}} to make use of it.
* '''Required skills'''
: Knowledge of Octave, C++ and C.
* '''Difficulty'''
: Medium.
* '''Potential mentor'''
: Carnë Draug
== PolarAxes and Plotting Improvements ==
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listeners to get things to work.  What is needed is the implementation of a dedicated "polaraxes" object in C++.  This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object.  When "polaraxes" exists as an object type, then m-files will be written to access them, including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m.  This relates to bug {{bug|49804}}.
* '''Minimum requirements'''
: Ability to read and write C++ code.  Ability to read and write Octave code.  Experience with OpenGL programming is optional.
* '''Difficulty'''
: Medium.
* '''Mentor'''
: Rik


== Adding functionality to packages ==
== Adding functionality to packages ==
Line 163: Line 202:
* '''Mentor'''
* '''Mentor'''
: Sebastian Schöps, Carlo de Falco
: Sebastian Schöps, Carlo de Falco
== Using Python within Octave ==
[[Pythonic]] allows one to call Python functions and interact with Python objects from within Octave .m file code and from the Octave command line interface.  Pythonic may eventually not be a separate package, but rather a core feature of Octave.  This project aims to improve Pythonic with the goal of making the package more stable, maintainable, and full-featured.
Based on a previous summer project related to Pythonic, this work will consist of fast-paced collaborative software development based on tackling the [https://gitlab.com/mtmiller/octave-pythonic/issues Pythonic issue list].  You would also be expected to participate in software design decisions and discussion, as well as improve documentation, doctests, and unit tests.  As an example of the sorts of decisions being made, note that Octave indexes from 1 whereas Python typically indexes from 0; in which cases is it appropriate to make this transparent to the user?
* '''Mentors'''
: Mike Miller, Colin B. Macdonald, Abhinav Tripathi, others?
== Improve TIFF image support ==
[https://en.wikipedia.org/wiki/TIFF Tag Image File Format (TIFF)] is the de facto standard for scientific images.  Octave uses the [http://www.graphicsmagick.org/ GraphicsMagic] (GM) C++ library to handle [http://www.graphicsmagick.org/formats.html TIFF and many others image formats]. However, GM still has several limitations:
* GM has build option {{codeline|quantum}} which defines the bitdepth to use when reading an image:
** Building GM with '''high quantum''' means that images of smaller bitdepth will take a lot more memory when reading.
** Building GM with '''low quantum''' will make it impossible to read images of higher bitdepth. It also means that the image needs to always be rescaled to the correct range.
* GM supports unsigned integers only, thus incorrectly reading files such as TIFF with floating-point data.
* GM hides details of the image such as whether the image file is indexed.  This makes it hard to access the real data stored on file.
This project aims to implement better TIFF image support using [https://en.wikipedia.org/wiki/Libtiff libtiff], while leaving GM handle all other image formats.  After writing a [https://octave.org/doc/v6.1.0/classdef-Classes.html classdef] interface to libtiff, improve the Octave functions {{manual|imread}}, {{manual|imwrite}}, and {{manual|imfinfo}} to make use of it.
* '''Required skills'''
: Knowledge of Octave, C++ and C.
* '''Difficulty'''
: Medium.
* '''Potential mentor'''
: Carnë Draug
== PolarAxes and Plotting Improvements ==
Octave currently provides supports for polar axes by using a Cartesian 2-D axes and adding a significant number of properties and callback listeners to get things to work.  What is needed is the implementation of a dedicated "polaraxes" object in C++.  This will require creating a new fundamental graphics object type, and programming in C++/OpenGL to render the object.  When "polaraxes" exists as an object type, then m-files will be written to access them, including polaraxes.m, polarplot.m, rticks.m, rticklabels.m, thetaticks, thetaticklabels.m, rlim.m, thetalim.m.  This relates to bug {{bug|49804}}.
* '''Minimum requirements'''
: Ability to read and write C++ code.  Ability to read and write Octave code.  Experience with OpenGL programming is optional.
* '''Difficulty'''
: Medium.
* '''Mentor'''
: Rik


[[Category:Summer of Code]]
[[Category:Summer of Code]]
[[Category:Project Ideas]]
[[Category:Project Ideas]]
Retrieved from "https://wiki.octave.org/Special:MobileDiff/13570"