To all those lamenting the slow development of ColorTypes.jl, Colors.jl, and so on
I had to leave the development a few years ago due to somewhat misfortunes. I apologize for the inconvenience.
I am in relatively good health now and need not worry about that. However, the circumstances surrounding me are certainly harsher than a few years ago.
There is a possibility that next time I may not come back permanently. (That could happen to anyone, though.)
For this reason, I made public the repositories for several packages that were being developed around 2020-2021.
All of the packages are incomplete in their basic implementation, but you might get a sense of the essence of what I wanted to do.
I will register them, once the basic functionality has been implemented, tested, and documented. That may be achieved within a year, or may be several years.
I don’t recommend forking them as I will push -f to the main branches for the time being. If you are interested in developing one of them, please contact me.
You could transfer them to the JuliaGraphics organization…There, they’ll hopefully outlive both you and me, and can be maintained and updated by any suitably-skilled Julians and their descendants!
As a basic policy, I agree with the transfer of these packages to the organizations.
The following is a summary of my concerns about each package.
ColorProfiles
ColorProfiles has a well-defined set of referenced standards and several reference open source implementations beyond the Julia language.
ColorProfiles is intentionally separate from color management systems. (I have a mostly empty private repository ColorManagement).
The transfer of ColorProfiles to the organization (JuliaGraphics) would be appropriate since its development does not depend on the skills of any particular person.
(Though, dare I say it, the development is not very creative and is a behind-the-scenes job.)
Other packages are relatively controversial.
As in the example of YCbCr, empirically, this kind of discussion does not converge in the community. We need a “dictator”.
Therefore, we will need to incubate them a bit more in local repositories.
Developing a framework for YUVColorTypes is tricky.
On the other hand, once the framework is established, it should be easy to add various profiles. (Speeding up will be somewhat tricky, though.)
Another issue is testing.
The environment surrounding YCbCr is so chaotic that we no longer know what is “correct”, even though there are the standard specifications. In fact, FFMPEG results and YUVColorTypes results do not match.
When the framework and testing concept is established, I think it is the right time to transfer it to the organization (JuliaGraphics).
Incidentally, like the relationship between HDRColorTypes and HDRImages, I have a private package YUVImages, which will support chroma subsampling in planar and packed formats. However, it has been stalled in the middle of its basic design because of too many format variations.
Perhaps I should concentrate my resources on the typical formats so that this can be released early.
The challenge with CMYKColorTypes is the default RGB<=>CMYK conversion.
For better or worse, ColorTypes are used by packages and users who are not color experts. If we implement a less-than-ideal default conversion, it will cause potential problems in many places.
It is one option to not explicitly support conversions (convert will give an error). However, we do not yet have a color management system compatible with the ColorTypes ecosystem. For many users, the error will be a hindrance, and they might implement a "worse” conversion to get around the error.
Most practical CMYK profiles are LUT-based, whereas most YCbCr profiles are specified with parametric curves and matrices.
It would not be practical for CMYKColorTypes to bundle CMYK color profiles.
In other words, the comprehensive approach of YUVColorTypes cannot be used with CMYKColorTypes.
There is no international agreement on a standard profile either.
In Japan, “Japan Color 2001 Coated” seems to be still the de facto standard as a general-purpose (exchangeable) profile (although “Japan Color 2011 Coated” has been out for more than 10 years). However, “Japan Color” is probably not used outside of Japan.
I was thinking of emulating “eciCMYK (FOGRA53)” as the default conversion. At least around 2021 when I was developing CMYKColorTypes, “eciCMYK v2 (FOGRA59)” was not in widespread use.
Now I think “eciCMYK v2” is more appropriate (Change default conversion reference from eciCMYK (FOGRA53) to eciCMYK v2 (FOGRA59) · Issue #2 · kimikage/CMYKColorTypes.jl · GitHub).
The current implementation uses polynomial approximation instead of the LUT, but people in the field of mathematical optimization and numerical modeling may be better at the implementation.
These are for the specific application of HDR imaging, so there are not many issues to discuss.
However, the current ColorTypes and its downstream packages often do not handle “lazy” colors like RGBE well (e.g. Improper handling of minor RGB pixel formats in saving · Issue #162 · tlnagy/TiffImages.jl · GitHub). (A similar problem exists with YUVColorTypes. However, since YUV-like colors are mostly used as a temporal intermediate form between integer-encoded YUV and fractional RGB, I don’t see much need for lazy evaluation.)
Note that I have published StorageColorTypes.jl (unregistered) in 2020 as an experimental package for “lazy” colors.
We may need to move forward with further support (higher level of abstraction implementation) of “lazy” formats for colors and images (color arrays).
I think JuliaGraphics is the appropriate organization to manage HDRColorTypes.
As for HDRImages, it is a bit unclear.
Currently HDRImages only implements a loader for Radiance HDR images, but that is not its main feature. I would like to implement some tone mapping functions there, similar to what is implemented in OpenCV. So at least JuliaIO is not the appropriate organization for HDRImages.
Global tone mapping is concluded in a color or pixel (thus, having that functionality in HDRColorTypes is one option). On the other hand, for example, histogram-based tone mapping is an “image” processing.
By the way, I am not a member of the JuliaGraphics organization, although I am a collaborator on several repositories there.
As long as I have write permission to the repositories, that is enough for me, I do not need to be a member of the organization.
That means I expect the repositories will be transferred through one of the members.
If I am not misunderstanding the process, I will list the to-do’s for the transfer in each repository issue.
