Re: Phobos colour module?
You can take a look at what color formats does freeimage supports.
Re: Phobos colour module?
And for completeness: http://en.wikipedia.org/wiki/CIECAM02
Re: Phobos colour module?
On Thursday, 8 January 2015 at 02:56:36 UTC, Manu via Digitalmars-d wrote: L*ab, L*CHab, HSL, HWB C#'s and Java's colour struct provides what they call HSB which is related to HSV. In computer vision a variant is HSI. http://en.wikipedia.org/wiki/HSL_and_HSV Java has a separate colour space type with quite extensive support, I guess that is a good reference for what is useful: http://docs.oracle.com/javase/7/docs/api/java/awt/color/ColorSpace.html http://docs.oracle.com/javase/7/docs/api/java/awt/Color.html
Re: Phobos colour module?
Ah yeah, supporting w3c standards is probably a sensible move. On 08/01/2015 9:55 am, "via Digitalmars-d" wrote: > On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote: > >> I think it can be interesting to provide some string formats can be >> directly converted into color structures. >> >> For example : >> - plain color names : "red", "blue", "light gray",... >> - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha) >> - decimal : "255, 158, 200", "255, 158, 200, 170" >> ... >> >> I think to that cause I saw many times tools using pretty close syntax >> for color definitions but with boring variations (generally for the alpha >> position). >> > > It is defined in a w3c standard and refined in a draft, but probably does > not belong in the colour module, but a media-file parser module? > > However, the at least the following colour spaces are mentioned as > supported in w3c documents: > > L*ab, L*CHab, HSL, HWB > > http://www.w3.org/TR/SVGColorPrimer12/ > > http://dev.w3.org/csswg/css-color/ > >
Re: Phobos colour module?
On Wednesday, 7 January 2015 at 20:57:51 UTC, Xavier Bigand wrote: I think it can be interesting to provide some string formats can be directly converted into color structures. For example : - plain color names : "red", "blue", "light gray",... - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha) - decimal : "255, 158, 200", "255, 158, 200, 170" ... I think to that cause I saw many times tools using pretty close syntax for color definitions but with boring variations (generally for the alpha position). It is defined in a w3c standard and refined in a draft, but probably does not belong in the colour module, but a media-file parser module? However, the at least the following colour spaces are mentioned as supported in w3c documents: L*ab, L*CHab, HSL, HWB http://www.w3.org/TR/SVGColorPrimer12/ http://dev.w3.org/csswg/css-color/
Re: Phobos colour module?
I think it can be interesting to provide some string formats can be directly converted into color structures. For example : - plain color names : "red", "blue", "light gray",... - hexadecimal : "#FF3CBB", "#FF3CBBAA" (same with alpha) - decimal : "255, 158, 200", "255, 158, 200, 170" ... I think to that cause I saw many times tools using pretty close syntax for color definitions but with boring variations (generally for the alpha position).
Re: Phobos colour module?
On Wednesday, 7 January 2015 at 00:30:20 UTC, Manu via Digitalmars-d wrote: On 7 January 2015 at 09:22, via Digitalmars-d wrote: For inspiration: http://golang.org/pkg/image/color/ Umm, is there something about this that you like? This looks... really terrible. Not particularly like, but it is the colour module for a comparable language. It reflects what they needed to implement other modules for image file formats. JPEG uses YCbCr: http://www.w3.org/Graphics/JPEG/jfif3.pdf I think it might be a good idea to do a survey of what other libraries provide and figure out why the provide it. That should give good "coverage".
Re: Phobos colour module?
On Wed, Jan 07, 2015 at 05:33:47PM +1100, Daniel Murphy via Digitalmars-d wrote: > "H. S. Teoh via Digitalmars-d" wrote in message > news:mailman.4232.1420610973.9932.digitalmar...@puremagic.com... > > >Ahhh now I remember what the problem was... there is no 80-bit > >integer type, so using union painting is the only way to work with > >reals in CTFE. > > I would rather we added intrinsics instead of using non-portable > unions/casts. If you can convince Walter, the more power to you! T -- Your inconsistency is the only consistent thing about you! -- KD
Re: Phobos colour module?
"H. S. Teoh via Digitalmars-d" wrote in message news:mailman.4232.1420610973.9932.digitalmar...@puremagic.com... Ahhh now I remember what the problem was... there is no 80-bit integer type, so using union painting is the only way to work with reals in CTFE. I would rather we added intrinsics instead of using non-portable unions/casts.
Re: Phobos colour module?
On Wed, Jan 07, 2015 at 04:13:37PM +1000, Manu via Digitalmars-d wrote: > On 7 January 2015 at 15:52, Daniel Murphy via Digitalmars-d > wrote: > > "Walter Bright" wrote in message news:m8haem$29hc$1...@digitalmars.com... > >> > >> I thought it did allow painting of the form *(cast(T*)&t). > > > > > > Only for float and double, not real. > > Wait up... aren't those function's heavily overloaded? I'm calling > with doubles, why would it call the real version? It isn't, it's probably failing because even the non-real version uses union painting to manipulate the bits, which CTFE currently doesn't support. T -- Кто везде - тот нигде.
Re: Phobos colour module?
On 7 January 2015 at 16:07, H. S. Teoh via Digitalmars-d wrote: > On Wed, Jan 07, 2015 at 04:52:25PM +1100, Daniel Murphy via Digitalmars-d > wrote: >> "Walter Bright" wrote in message news:m8haem$29hc$1...@digitalmars.com... >> >> >I thought it did allow painting of the form *(cast(T*)&t). >> >> Only for float and double, not real. > > Ahhh now I remember what the problem was... there is no 80-bit integer > type, so using union painting is the only way to work with reals in > CTFE. > > Of course, this *could* be construed to be a nail in the real coffin, > seeing that real is purportedly slower on modern hardware due to x87 > being gradually phased out... At very least, I would *really* like a compiler flag to disable real, or alias real=double to match other architectures. I have never had a use for real, it can only lead to problems for me, especially portability problems.
Re: Phobos colour module?
On 7 January 2015 at 15:52, Daniel Murphy via Digitalmars-d wrote: > "Walter Bright" wrote in message news:m8haem$29hc$1...@digitalmars.com... >> >> I thought it did allow painting of the form *(cast(T*)&t). > > > Only for float and double, not real. Wait up... aren't those function's heavily overloaded? I'm calling with doubles, why would it call the real version?
Re: Phobos colour module?
On Wed, Jan 07, 2015 at 04:52:25PM +1100, Daniel Murphy via Digitalmars-d wrote: > "Walter Bright" wrote in message news:m8haem$29hc$1...@digitalmars.com... > > >I thought it did allow painting of the form *(cast(T*)&t). > > Only for float and double, not real. Ahhh now I remember what the problem was... there is no 80-bit integer type, so using union painting is the only way to work with reals in CTFE. Of course, this *could* be construed to be a nail in the real coffin, seeing that real is purportedly slower on modern hardware due to x87 being gradually phased out... T -- Trying to define yourself is like trying to bite your own teeth. -- Alan Watts
Re: Phobos colour module?
"Walter Bright" wrote in message news:m8haem$29hc$1...@digitalmars.com... I thought it did allow painting of the form *(cast(T*)&t). Only for float and double, not real.
Re: Phobos colour module?
On 7 January 2015 at 00:28, Manu wrote: > On 6 January 2015 at 19:31, via Digitalmars-d > wrote: >> On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote: >>> >>> What's wrong with old-fashioned `Fast` postfixes on entry points where a >>> faster but less precise method is available? Or template arguments like >>> std.algorithm.SortStrategy? >> >> >> If this is for phobos it should follow a common model. But since a fast >> implementation might involve an object which builds a table before >> processing >> >> Another problem is that "precise" is a very loose term if the conversion is >> for display or for composition in a shader. What you want depends on the >> kind of post processing that happens after this and how it affects the >> nonlinearities of human perception. > > I think an important facet of 'fast' image processing is in the loop > that processes batches of pixels, rather than in the api that > processes a single pixel. > I've gone with accurate; that's the strategy throughout phobos. > > I can't create look-up-tables at the moment, since '^^' doesn't work > in CTFE! >_< > > Here's a PR to see where I'm at: > https://github.com/D-Programming-Language/phobos/pull/2845 I'd like to get some ideas from people what basic colour operations people would like/expect to see. I'm also pondering which operators should be supported. Do people think it makes any sense to support unary -? They're only really useful in cases like normal maps, and don't make sense on unsigned+normalised colour types. What about unary ~? Bitwise not doesn't really have any meaning in terms of colour, but it might make sense for the operator to calculate the negative colour... although that kinda feels like operator abuse to me. What should happen when operators are applied to colours of differing colour space? I kinda feel like denying operators on colour space mismatch. It's not clear which format (left/right hand side) should be the preferred format for the operation/result... I'm also questioning whether implicit assignment colour conversion should be allowed (and this kinda relates to restricting operators to like-types. Alternatively I can limit conversion to explicit cast operator or to!. What about scalar operators, ie, to scale a colour? should the scalar argument be expected to match the datatype, or support float against all types for scaling? (slow! int->float->int conversion for a basic mul!) What details have I missed?
Re: Phobos colour module?
On 7 January 2015 at 09:22, via Digitalmars-d wrote: > For inspiration: > > http://golang.org/pkg/image/color/ Umm, is there something about this that you like? This looks... really terrible.
Re: Phobos colour module?
For inspiration: http://golang.org/pkg/image/color/
Re: Phobos colour module?
On Tue, Jan 06, 2015 at 10:44:38AM -0800, Walter Bright via Digitalmars-d wrote:
> On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote:
> >Implementing union painting in CTFE would singlehandedly solve
> >(almost?) all of std.math CTFE issues, AFAICT.
>
> I thought it did allow painting of the form *(cast(T*)&t).
Was that a recent addition? I don't remember that working last year.
In any case, the current std.math code tries to achieve repainting via
unions, which currently doesn't work in CTFE:
ulong ctfeFunc(double d) {
union U {
double f;
ulong ul;
}
U u;
u.f = d;
return u.ul;// <--- CTFE error
}
enum x = ctfeFunc(3.141592);
Maybe I remembered wrong, but the original std.math code relied on
*(cast(T*)&t) to work, but was rewritten to use union repainting, IIRC
because union painting is considered more likely to be implemented in
CTFE (? -- my guess; I could be wrong).
In any case, it's great news that repainting is now supported in CTFE.
Hopefully this means more of std.math will be usable at compile-time
soon!
T
--
"The whole problem with the world is that fools and fanatics are always so
certain of themselves, but wiser people so full of doubts." -- Bertrand
Russell. "How come he didn't put 'I think' at the end of it?" -- Anonymous
Re: Phobos colour module?
On 1/6/2015 10:07 AM, H. S. Teoh via Digitalmars-d wrote: Implementing union painting in CTFE would singlehandedly solve (almost?) all of std.math CTFE issues, AFAICT. I thought it did allow painting of the form *(cast(T*)&t).
Re: Phobos colour module?
On Tue, Jan 06, 2015 at 06:28:03PM +, via Digitalmars-d wrote: > On Tuesday, 6 January 2015 at 18:09:19 UTC, H. S. Teoh via Digitalmars-d > wrote: > >It's the non-integral exponents that require the > >currently-non-CTFE-able code, right? > > http://en.wikipedia.org/wiki/Gamma_correction Right, integral exponents aren't the interesting (useful) case here. T -- Valentine's Day: an occasion for florists to reach into the wallets of nominal lovers in dire need of being reminded to profess their hypothetical love for their long-forgotten.
Re: Phobos colour module?
On Tuesday, 6 January 2015 at 18:09:19 UTC, H. S. Teoh via Digitalmars-d wrote: It's the non-integral exponents that require the currently-non-CTFE-able code, right? http://en.wikipedia.org/wiki/Gamma_correction
Re: Phobos colour module?
On Tue, Jan 06, 2015 at 09:52:57AM -0800, Andrei Alexandrescu via Digitalmars-d
wrote:
> On 1/6/15 6:28 AM, Manu via Digitalmars-d wrote:
> >I can't create look-up-tables at the moment, since '^^' doesn't work
> >in CTFE! >_<
>
> Assuming the exponent is integral, could you write a naive pow()
> function that works in ctfe? -- Andrei
I thought std.math already has an overload for pow() that works with
integral exponents?
In any case, a naïve CTFE implementation would be as simple as:
T pow(T, U)(T t, U exp)
if (isIntegral!U)
{
T result = 1;
foreach (_; 0 .. abs(exp))
result *= t;
return (exp < 0) ? 1 / result : result;
}
It's the non-integral exponents that require the currently-non-CTFE-able
code, right?
In any case, pow() itself isn't the cause of non-CTFE-ability, since
Iain has so kindly provided "native" D implementations of pow() (and
most (all?) other standard math functions) in std.math; it's just that
floating-point primitives like isInfinite currently can't be CTFE'd
because they require access to the bit representation of the floats
which CTFE currently doesn't allow.
Implementing union painting in CTFE would singlehandedly solve (almost?)
all of std.math CTFE issues, AFAICT.
T
--
Almost all proofs have bugs, but almost all theorems are true. -- Paul Pedersen
Re: Phobos colour module?
On 1/6/15 6:28 AM, Manu via Digitalmars-d wrote: I can't create look-up-tables at the moment, since '^^' doesn't work in CTFE! >_< Assuming the exponent is integral, could you write a naive pow() function that works in ctfe? -- Andrei
Re: Phobos colour module?
On Tuesday, 6 January 2015 at 14:28:52 UTC, Manu via Digitalmars-d wrote: I think an important facet of 'fast' image processing is in the loop that processes batches of pixels, rather than in the api that processes a single pixel. I've gone with accurate; that's the strategy throughout phobos. Yeah, I agree. For fast on the CPU you want to use simd, and maybe one register for red, another for green, using saturating instructions, doing it differently on ARM vs x86 etc... Besides, an accurate reference implementation is a good starting point and also very useful for unit testing a faster batch-oriented version later on. Here's a PR to see where I'm at: https://github.com/D-Programming-Language/phobos/pull/2845 Nice start. Most libraries use US-English "color", though. I guess phobos should try to be internally consistent (pick either UK or US vocabulary).
Re: Phobos colour module?
On 6 January 2015 at 19:31, via Digitalmars-d wrote: > On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote: >> >> What's wrong with old-fashioned `Fast` postfixes on entry points where a >> faster but less precise method is available? Or template arguments like >> std.algorithm.SortStrategy? > > > If this is for phobos it should follow a common model. But since a fast > implementation might involve an object which builds a table before > processing > > Another problem is that "precise" is a very loose term if the conversion is > for display or for composition in a shader. What you want depends on the > kind of post processing that happens after this and how it affects the > nonlinearities of human perception. I think an important facet of 'fast' image processing is in the loop that processes batches of pixels, rather than in the api that processes a single pixel. I've gone with accurate; that's the strategy throughout phobos. I can't create look-up-tables at the moment, since '^^' doesn't work in CTFE! >_< Here's a PR to see where I'm at: https://github.com/D-Programming-Language/phobos/pull/2845
Re: Phobos colour module?
On Tuesday, 6 January 2015 at 09:19:46 UTC, John Colvin wrote: What's wrong with old-fashioned `Fast` postfixes on entry points where a faster but less precise method is available? Or template arguments like std.algorithm.SortStrategy? If this is for phobos it should follow a common model. But since a fast implementation might involve an object which builds a table before processing Another problem is that "precise" is a very loose term if the conversion is for display or for composition in a shader. What you want depends on the kind of post processing that happens after this and how it affects the nonlinearities of human perception.
Re: Phobos colour module?
On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d wrote: On 6 January 2015 at 04:11, via Digitalmars-d wrote: On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote: Yeah, in my misc repo, there used to be stand along image.d and simpledisplay.d. Now, they both depend on color.d. Even just a basic definition we can use elsewhere is nice to have so other libs can interop on that level without annoying casts or pointless conversions just to please the type system when the contents are identical. Yes, that too. I was more thinking about the ability to create an adapter that extracts colour information from an existing data structure and adds context information such as gamma. Then let you build a function that say reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit RGB pixel with gamma correction and the residue in a specified format suitable for dithering... ;-] It is quite common error to do computations on colours that are ignorant of gamma (or do it wrong) which results in less accurate imaging. E.g. When dithering you need to make sure that the residue that is left when doing bit truncation is added to the neighbouring pixels in a "linear addition" (without gamma). Making stuff like that less tedious would make it a very useful library. I have thought about how to handle residue from lossy-encoding, but I haven't thought of an API I like for that yet. Dithering operates on neighbourhoods of pixels, so in some ways I feel it is beyond the scope of colour.d, but residue is an important detail to enable dithering that should probably be expressed while encoding. Currently, I have a colour template which can be arbitrarily typed and components defined in some user-specified order. It binds the colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is defined and performs arbitrary conversions between colours. I'm finding myself at a constant struggle between speed and maximizing-precision. I feel like a lib should maximise precision, but the trouble then is that it's not actually useful to me... Very few applications care about colour precision beyond ubyte, so I feel like using double for much of the processing is overkill :/ I'm not sure what the right balance would look like exactly. I can make fast-paths for common formats, like ubyte conversions between sRGB/Linear, etc use tables. Performing colourspace conversions in fixed point (where both sides of conversion are integer types) might be possible without significant loss of precision, but it's tricky... I just pipe through double now, and that's way overkill. I'll make a PR tonight some time for criticism. What's wrong with old-fashioned `Fast` postfixes on entry points where a faster but less precise method is available? Or template arguments like std.algorithm.SortStrategy?
Re: Phobos colour module?
On Tuesday, 6 January 2015 at 08:52:06 UTC, Ola Fosheim Grøstad wrote: - with negative values you can then have a unique representation of a single colour in CIE (the theoretical base for RGB that was developed in the 1930s). Actually, what I refer to here is a model of how humans perceive colour: http://en.wikipedia.org/wiki/CIE_1931_color_space#CIE_standard_observer
Re: Phobos colour module?
On Monday, 5 January 2015 at 23:39:17 UTC, Manu via Digitalmars-d wrote: I'm finding myself at a constant struggle between speed and maximizing-precision. I feel like a lib should maximise precision, but the trouble then is that it's not actually useful to me... If you create a "pixel" converter that aims for speed, the programmer might also want it to generate a shader (as text string) with exactly the same properties. It makes less and less sense to create a performant imaging library that is CPU only. I suggest reducing the scope to: 1. Provide generic accurate conversion and iterators for colours (or more general; for arrays of spectral values). Useful for doing batch like stuff or initialization. 2. Provide fast colour support for transforms that are simple enough to not warrant GPU processing, but where you accept the cost of building lookup tables before processing. (Build tables using (1).) Very few applications care about colour precision beyond ubyte, so I feel like using double for much of the processing is overkill :/ I'm not sure what the right balance would look like exactly. I think a precise reference implementation using double is a good start. People creating PDFs, SVGs or some other app that does not have real time requirements probably want that. It is also useful for building LUTs. One thing to consider is that you also might want to handle colour compontents that have negative values or values larger than 1.0: - it is useful in non-realistic rendering as "darklights" ( http://www.glassner.com/wp-content/uploads/2014/04/Darklights.pdf ) - with negative values you can then have a unique representation of a single colour in CIE (the theoretical base for RGB that was developed in the 1930s). - it allows the programmer to do his own gamut compression after conversion
Re: Phobos colour module?
On 6 January 2015 at 04:11, via Digitalmars-d wrote: > On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote: >> >> Yeah, in my misc repo, there used to be stand along image.d and >> simpledisplay.d. Now, they both depend on color.d. Even just a basic >> definition we can use elsewhere is nice to have so other libs can interop on >> that level without annoying casts or pointless conversions just to please >> the type system when the contents are identical. > > > Yes, that too. I was more thinking about the ability to create an adapter > that extracts colour information from an existing data structure and adds > context information such as gamma. Then let you build a function that say > reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit > RGB pixel with gamma correction and the residue in a specified format > suitable for dithering... ;-] > > It is quite common error to do computations on colours that are ignorant of > gamma (or do it wrong) which results in less accurate imaging. E.g. When > dithering you need to make sure that the residue that is left when doing bit > truncation is added to the neighbouring pixels in a "linear addition" > (without gamma). Making stuff like that less tedious would make it a very > useful library. I have thought about how to handle residue from lossy-encoding, but I haven't thought of an API I like for that yet. Dithering operates on neighbourhoods of pixels, so in some ways I feel it is beyond the scope of colour.d, but residue is an important detail to enable dithering that should probably be expressed while encoding. Currently, I have a colour template which can be arbitrarily typed and components defined in some user-specified order. It binds the colourspace to colours. 'CTo to(CTo, CFrom)(CFrom colour)' is defined and performs arbitrary conversions between colours. I'm finding myself at a constant struggle between speed and maximizing-precision. I feel like a lib should maximise precision, but the trouble then is that it's not actually useful to me... Very few applications care about colour precision beyond ubyte, so I feel like using double for much of the processing is overkill :/ I'm not sure what the right balance would look like exactly. I can make fast-paths for common formats, like ubyte conversions between sRGB/Linear, etc use tables. Performing colourspace conversions in fixed point (where both sides of conversion are integer types) might be possible without significant loss of precision, but it's tricky... I just pipe through double now, and that's way overkill. I'll make a PR tonight some time for criticism.
Re: Phobos colour module?
On Monday, 5 January 2015 at 16:08:27 UTC, Adam D. Ruppe wrote: Yeah, in my misc repo, there used to be stand along image.d and simpledisplay.d. Now, they both depend on color.d. Even just a basic definition we can use elsewhere is nice to have so other libs can interop on that level without annoying casts or pointless conversions just to please the type system when the contents are identical. Yes, that too. I was more thinking about the ability to create an adapter that extracts colour information from an existing data structure and adds context information such as gamma. Then let you build a function that say reads floats from 3 LAB pointers and finally returns a tuple with a 16 bit RGB pixel with gamma correction and the residue in a specified format suitable for dithering... ;-] It is quite common error to do computations on colours that are ignorant of gamma (or do it wrong) which results in less accurate imaging. E.g. When dithering you need to make sure that the residue that is left when doing bit truncation is added to the neighbouring pixels in a "linear addition" (without gamma). Making stuff like that less tedious would make it a very useful library.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. Indeed, I stop you right there: I did one as well in the past, but definitively not high quality enough to be interesting for 3rd party. Does it seem like something we should see added to phobos? Yes.
Re: Phobos colour module?
On Monday, 5 January 2015 at 15:57:32 UTC, Ola Fosheim Grøstad
wrote:
But I agree that colour theory is solid enough to be considered
stable and that it would be a great benefit to have a single
library used across multiple projects. It is also very suitable
for templated types.
Yeah, in my misc repo, there used to be stand along image.d and
simpledisplay.d. Now, they both depend on color.d. Even just a
basic definition we can use elsewhere is nice to have so other
libs can interop on that level without annoying casts or
pointless conversions just to please the type system when the
contents are identical.
I went with struct Color { ubyte r,g,b,a; } not perfect,
probably not good enough for like a Photoshop, and sometimes the
bytes need to be shuffled for different formats, but eh it works
for me.
Re: Phobos colour module?
On Friday, 2 January 2015 at 08:46:25 UTC, Manu via Digitalmars-d wrote: Not universal enough? Colours are not exactly niche. Loads of system api's, image readers/writers, icons, they all use pixel buffers. A full-blown image library will require a lot more design work, sure, but I can see room for that in Phobos too. I feel Phobos need to be broken up. There is too much esoteric stuff in there and too much essential stuff missing. I think some kind of "extra" hierarchy is needed for more application specific functionality. But I agree that colour theory is solid enough to be considered stable and that it would be a great benefit to have a single library used across multiple projects. It is also very suitable for templated types. A standard image library would have to be templated with optional compiler-specific optimizations (SIMD) for the most usual combination. There are too many representations used in different types of image processing to find common ground (unless you limit yourself and just select PNG as your design base).
Re: Phobos colour module?
Le 01/01/2015 07:38, Manu via Digitalmars-d a écrit : I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. Does it seem like something we should see added to phobos? My colours can be used as high-level colour values for precise numeric work, or specify encodings such that they are directly useful to represent pixels in images of basically any format/layout for rendering use. Unlike a full-blown image library which will often be implemented in different ways for different uses, I can't imagine colours/pixels could have a great number of implementation styles where different API's would have any reason to compete, and as such, it seems like a nice thing to standardise. Standardised colours would make it *much* easier for competing image libraries to interact. With standard colours, image libraries would tend to distinguish themselves in terms of memory management, data layout, image processing patterns and api, etc. Those are all valid cases for different designs, but I can't imagine any reason for distinct colour api's. Comprehensive colour-space management and minimum-loss encoding is a lot of work, and almost every implementation ignores facets of the puzzle that aren't obviously relevant. It would give a good foundation for other std.image related libraries to be built on top. I'm also working on a graphing lib, and that requires to output images. It would be *really* nice to support common image format readers/writers in the std library which need to handle pixel data. Thoughts? I will enjoy to see a colour/image module in phobos a day. There is some filters very usefull that are almost unknow like the per-multiplied alpha bleeding need to be democratized to improve GUI rendering quality. There is so much issues on images data when rendering on GPU that have common fix make me think phobos is a great place for such modules. Some explainations : https://www.youtube.com/watch?v=dU9AXzCabiM
Re: Phobos colour module?
On Thursday, 1 January 2015 at 12:39:37 UTC, Peter Alexander wrote: Maybe just put it on code.dlang for now, and then add it together with an image library later? This should imho be the standard way of submitting code to Phobos these days anyway. Put it up on code.dlang.org, have a couple of people actually use and review it there, and then (and only then) submit it for std.experimental. This way, we can hopefully avoid the epic discussions from previous review threads where people first comment on small details and only later discover that the library has major design defects that would inhibit real-world use. (That's not to say that I haven't been guilty of contributing to such threads too.) David
Re: Phobos colour module?
On 2 January 2015 at 08:21, Brad Anderson via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: >> >> [snip] >> Thoughts? > > > I don't think something like this belongs in phobos. It's not universal > enough to warrant all the extra work it would require to add and maintain in > phobos. Not universal enough? Colours are not exactly niche. Loads of system api's, image readers/writers, icons, they all use pixel buffers. A full-blown image library will require a lot more design work, sure, but I can see room for that in Phobos too. There are a lot of tasks that you can't really just download D and get to work on, particularly in the realm of UI and multimedia, which are important tasks. > There are significant advantages to doing it as a dub project: > > - Not being locked into phobo's irregular update cycle > - Making use of other third party libraries > - Easier to control how it is built (the distributed phobos isn't even built > with inlining enabled currently) > - Easier to accept pull requests for cases where the author isn't a phobos > committer > - Much more freedom to break code while still letting people use an old > version if they can't do the necessary updates for whatever reason > > I'd love having access to something like this though. My own color stuff is > always cobbled together from code gathered from random websites and I'm > rarely confident I implemented them correctly or efficiently. Yeah, it's probably actually the hardest part of image processing jobs, and it's also the least debatable about what's 'right'. The layers that could be built on top could be varied and remain fairly lean.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: [snip] Thoughts? I don't think something like this belongs in phobos. It's not universal enough to warrant all the extra work it would require to add and maintain in phobos. There are significant advantages to doing it as a dub project: - Not being locked into phobo's irregular update cycle - Making use of other third party libraries - Easier to control how it is built (the distributed phobos isn't even built with inlining enabled currently) - Easier to accept pull requests for cases where the author isn't a phobos committer - Much more freedom to break code while still letting people use an old version if they can't do the necessary updates for whatever reason I'd love having access to something like this though. My own color stuff is always cobbled together from code gathered from random websites and I'm rarely confident I implemented them correctly or efficiently.
Re: Phobos colour module?
Manu: I would do that to start with, but the difference is that if I work with phobos in mind, then I'll raise design discussion here, otherwise I'll just keep it to myself. I think having a color module in Phobos is OK. But probably it's better to write it with Phobos in mind but to keep it in code.dlang for some time, like one year, to refine its API, before adding it to Phobos. Bye, bearophile
Re: Phobos colour module?
On 2 January 2015 at 02:06, ponce via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via Digitalmars-d wrote: >> >> I feel like the colour space should be attached to the colour. Why would >> you make it a separate object? >> > > If the color space is a runtime object (eg from parsing a CC profile) then I > would be wary of any additional memory it could use, hence necessity to pass > it separately. For a single color value alone, not a problem. > If it is a template parameter, no such problem exist, it would be attached > as template argument to Color. But then, you can't parse CC profiles! > Headache ensue. > > It's like we need a compile-time parameter that would be a runtime one > sometimes, like in many D designs. Maybe there is an escape hatch with a > template being some sort of std.variant of color-spaces. Right, I see. Good idea, I'm sure there's a clear solution here. I think possibly just some 'unspecified' colour space, and that would cause no implicit colour space conversions to happen...? It would be up to the user to make calls to appropriate conversion functions according to whatever runtime data they have. That said, as I see it, runtime colour space is not a concept that's useful applied to single pixels; that would be horrendously slow or memory consuming. It would need to be managed at the image level, and pixels would have to have 'unspecified' colour space at compile time, and rely on image level API's to perform runtime colour space conversions. I'm also a bit dubious about the usefulness of an 'unknown' colour space at all... almost all tasks imply a specific colour space. Reading/writing images from disk, rendering to displays, printing, etc, are all operations that expect very particular colour space. Image processing algorithms are usually quite dependant on particular colour space. I can't imagine a generic image processing algorithm that works with any runtime given colour space. I think it would be known at compile time in almost all cases. I can't imagine a case where it wouldn't. >> I think image work in phobos needs to be taken in steps, and should >> probably start with the simplest and most useful shared primitives >> first. >> Colour would offer massive bang-for-buck in terms of getting different >> 3rd party modules talking to eachother. > > > Be our cook :) Well maybe Vladimir would like to get involved? It looks like he's put a lot of time into this already.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 15:46:07 UTC, Manu via Digitalmars-d wrote: On 2 January 2015 at 01:09, ponce via Digitalmars-d wrote: On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. There is such an effort in https://github.com/CyberShadow/ae/blob/master/utils/graphics/color.d Could give some ideas for a more general solution. Haha, it's surprisingly similar to what I already have! Except my colour also has a colour space which is properly accounted when doing casts or assignments. Yes, this one is pretty much untyped. There is a lot of complications because images can be stored interleaved, with various pitch, also in video there exist cases where the several planes have different dimension (2x or 4x smaller) and this would be nice to account, albeit not an absolute necessity. That's why I don't want to deal with images to start with ;) I think we can get a colour in there. Images will lead to massive debate. Agreed. The number of color space is also astounding, and then do we store it as a template parameter or a runtime object? I feel like the colour space should be attached to the colour. Why would you make it a separate object? If the color space is a runtime object (eg from parsing a CC profile) then I would be wary of any additional memory it could use, hence necessity to pass it separately. For a single color value alone, not a problem. If it is a template parameter, no such problem exist, it would be attached as template argument to Color. But then, you can't parse CC profiles! Headache ensue. It's like we need a compile-time parameter that would be a runtime one sometimes, like in many D designs. Maybe there is an escape hatch with a template being some sort of std.variant of color-spaces. I think image work in phobos needs to be taken in steps, and should probably start with the simplest and most useful shared primitives first. Colour would offer massive bang-for-buck in terms of getting different 3rd party modules talking to eachother. Be our cook :)
Re: Phobos colour module?
On 2 January 2015 at 01:09, ponce via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: >> >> I've been working on a pretty comprehensive module for dealing with >> colours in various formats and colour spaces and conversions between >> all of these. >> It seems like a hot area for duplicated effort, since anything that >> deals with multimedia will need this, and I haven't seen a really >> comprehensive implementation. > > > There is such an effort in > https://github.com/CyberShadow/ae/blob/master/utils/graphics/color.d > Could give some ideas for a more general solution. Haha, it's surprisingly similar to what I already have! Except my colour also has a colour space which is properly accounted when doing casts or assignments. >> Does it seem like something we should see added to phobos? >> > > Image concept + planar bitmap implementing would be really nice. Vladimir has already made a great start on that it seems. > There is a lot of complications because images can be stored interleaved, > with various pitch, also in video there exist cases where the several planes > have different dimension (2x or 4x smaller) and this would be nice to > account, albeit not an absolute necessity. That's why I don't want to deal with images to start with ;) I think we can get a colour in there. Images will lead to massive debate. > The number of color space is also astounding, and then do we store it as a > template parameter or a runtime object? I feel like the colour space should be attached to the colour. Why would you make it a separate object? > Currently one can separate readers/writers from data structure using AE > graphics module. I woudln't mind something at least as good :) Seems he's already done heaps of this work. Perhaps it would be best for Vladimir to push on this stuff instead? > Standardizing on std.color first looks like a good first step towards > std.image (or shouldn't it be: std.multidimarray?). Exactly, it's highly debatable! ;) I think image work in phobos needs to be taken in steps, and should probably start with the simplest and most useful shared primitives first. Colour would offer massive bang-for-buck in terms of getting different 3rd party modules talking to eachother.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. There is such an effort in https://github.com/CyberShadow/ae/blob/master/utils/graphics/color.d Could give some ideas for a more general solution. Does it seem like something we should see added to phobos? Image concept + planar bitmap implementing would be really nice. There is a lot of complications because images can be stored interleaved, with various pitch, also in video there exist cases where the several planes have different dimension (2x or 4x smaller) and this would be nice to account, albeit not an absolute necessity. The number of color space is also astounding, and then do we store it as a template parameter or a runtime object? My colours can be used as high-level colour values for precise numeric work, or specify encodings such that they are directly useful to represent pixels in images of basically any format/layout for rendering use. Unlike a full-blown image library which will often be implemented in different ways for different uses, I can't imagine colours/pixels could have a great number of implementation styles where different API's would have any reason to compete, and as such, it seems like a nice thing to standardise. Standardised colours would make it *much* easier for competing image libraries to interact. With standard colours, image libraries would tend to distinguish themselves in terms of memory management, data layout, image processing patterns and api, etc. Those are all valid cases for different designs, but I can't imagine any reason for distinct colour api's. Comprehensive colour-space management and minimum-loss encoding is a lot of work, and almost every implementation ignores facets of the puzzle that aren't obviously relevant. It would give a good foundation for other std.image related libraries to be built on top. I'm also working on a graphing lib, and that requires to output images. It would be *really* nice to support common image format readers/writers in the std library which need to handle pixel data. Thoughts? Currently one can separate readers/writers from data structure using AE graphics module. I woudln't mind something at least as good :) Standardizing on std.color first looks like a good first step towards std.image (or shouldn't it be: std.multidimarray?).
Re: Phobos colour module?
On 1 January 2015 at 20:28, Jacob Carlborg via Digitalmars-d wrote: > On 2015-01-01 07:38, Manu via Digitalmars-d wrote: >> >> I've been working on a pretty comprehensive module for dealing with >> colours in various formats and colour spaces and conversions between >> all of these. >> It seems like a hot area for duplicated effort, since anything that >> deals with multimedia will need this, and I haven't seen a really >> comprehensive implementation. >> >> Does it seem like something we should see added to phobos? > > > I basically know nothing about this, but would this be compatible with the > various image/graphics C libraries out there? That would absolutely be a critical design goal. Fortunately, colours in C are usually expressed in very common ways. I'm toying over exactly how I want the API should look, and if people are behind this, then maybe I'll bring the discussion public?
Re: Phobos colour module?
On 2 January 2015 at 00:59, Dicebot via Digitalmars-d wrote: > Something that creates an API bridge between different external libraries is > naturally a good fit for Phobos and exactly type of additions I'd like to > see there. I think only concern is where exactly to put it : > std.media.image.colour sounds like a most fitting qualified path to me but > that is quite the hierarchy for a single module :) It would be good to start fleshing that tree out!
Re: Phobos colour module?
On 1 January 2015 at 23:11, Andrej Mitrovic via Digitalmars-d wrote: > On 1/1/15, Manu via Digitalmars-d wrote: >> Does it seem like something we should see added to phobos? > > You're likely to have more success making it an independent library > and putting it on code.dlang.org. > > Remember that tying the library to Phobos means that any bugs fixed > will only reach people after a new version of DMD+Phobos is released, > and releases are infrequent. I would do that to start with, but the difference is that if I work with phobos in mind, then I'll raise design discussion here, otherwise I'll just keep it to myself.
Re: Phobos colour module?
Something that creates an API bridge between different external libraries is naturally a good fit for Phobos and exactly type of additions I'd like to see there. I think only concern is where exactly to put it : std.media.image.colour sounds like a most fitting qualified path to me but that is quite the hierarchy for a single module :)
Re: Phobos colour module?
On 1 January 2015 at 21:30, via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: >> >> My colours can be used as high-level colour values for precise numeric >> work, or specify encodings such that they are directly useful to >> represent pixels in images of basically any format/layout for >> rendering use. > > > Colourspaces is a tricky area, it would be nice with a templated conversion > tool, but you also need to deal with stuff like gamut compression if you > want it to be a generic solution. > > http://www.colorwiki.com/wiki/Gamut_Compression Sure, that would definitely be a function offered. Ie, compress one colour space into another, as opposed to doing a direct colour space conversion, which could lead to clipping or unused headroom. CMYK is a bit tricky, since it usually relies on OS registered colour profiles; I'd probably leave CMYK conversion to a printing module. Other colour spaces are not hardware or OS specific, and should all be easy to support.
Re: Phobos colour module?
On 1 January 2015 at 22:43, Phil via Digitalmars-d wrote: >> >> I think it would be a nice addition, but might seem a bit lonely on its >> own, without an image library. Maybe just put it on code.dlang for now, and >> then add it together with an image library later? > > > This would be helpful to me even without an accompanying image > library. I have no idea about criteria for including in Phobos > though. I guess, people agree on it's necessity, and the design is approved?
Re: Phobos colour module?
On 1 January 2015 at 22:39, Peter Alexander via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: >> >> I've been working on a pretty comprehensive module for dealing with >> colours in various formats and colour spaces and conversions between >> all of these. >> It seems like a hot area for duplicated effort, since anything that >> deals with multimedia will need this, and I haven't seen a really >> comprehensive implementation. >> >> Does it seem like something we should see added to phobos? > > > I think it would be a nice addition, but might seem a bit lonely on its own, > without an image library. Maybe just put it on code.dlang for now, and then > add it together with an image library later? I expect that would come after. The thing about an image library though is it's a lot more debatable how it should look. Colours don't really have much room for argument; it's complete and efficient, or it's not. At very least, once we have colours in phobos, then we can add modules to read/write image files, which is quite a sore vacancy. We should also be able to interact with OS calls that deal with image data more conveniently.
Re: Phobos colour module?
On 1/1/15, Manu via Digitalmars-d wrote: > Does it seem like something we should see added to phobos? You're likely to have more success making it an independent library and putting it on code.dlang.org. Remember that tying the library to Phobos means that any bugs fixed will only reach people after a new version of DMD+Phobos is released, and releases are infrequent.
Re: Phobos colour module?
I think it would be a nice addition, but might seem a bit lonely on its own, without an image library. Maybe just put it on code.dlang for now, and then add it together with an image library later? This would be helpful to me even without an accompanying image library. I have no idea about criteria for including in Phobos though.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. Does it seem like something we should see added to phobos? I think it would be a nice addition, but might seem a bit lonely on its own, without an image library. Maybe just put it on code.dlang for now, and then add it together with an image library later?
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:38:41 UTC, Manu via Digitalmars-d wrote: My colours can be used as high-level colour values for precise numeric work, or specify encodings such that they are directly useful to represent pixels in images of basically any format/layout for rendering use. Colourspaces is a tricky area, it would be nice with a templated conversion tool, but you also need to deal with stuff like gamut compression if you want it to be a generic solution. http://www.colorwiki.com/wiki/Gamut_Compression
Re: Phobos colour module?
On 2015-01-01 07:38, Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. Does it seem like something we should see added to phobos? I basically know nothing about this, but would this be compatible with the various image/graphics C libraries out there? -- /Jacob Carlborg
Re: Phobos colour module?
On Thu, 01 Jan 2015 07:00:53 + Tofu Ninja via Digitalmars-d wrote: > On Thursday, 1 January 2015 at 06:47:14 UTC, ketmar via > Digitalmars-d wrote: > > On Thu, 1 Jan 2015 16:38:32 +1000 > > Manu via Digitalmars-d wrote: > > > >> Does it seem like something we should see added to phobos? > > i think that this will be a valuable addition. i really tired of > > copypasting various color model conversion code, for example, > > and i can > > never do that to the extent of "real" module. it will be great > > if > > Phobos will have tools for working with colors out of the box. > > Yes please. ah, that maillist quirks again... the original post is here: http://forum.dlang.org/thread/mailman.3926.1420094321.9932.digitalmar...@puremagic.com signature.asc Description: PGP signature
Re: Phobos colour module?
On 1/01/2015 7:38 p.m., Manu via Digitalmars-d wrote: I've been working on a pretty comprehensive module for dealing with colours in various formats and colour spaces and conversions between all of these. It seems like a hot area for duplicated effort, since anything that deals with multimedia will need this, and I haven't seen a really comprehensive implementation. Does it seem like something we should see added to phobos? My colours can be used as high-level colour values for precise numeric work, or specify encodings such that they are directly useful to represent pixels in images of basically any format/layout for rendering use. Unlike a full-blown image library which will often be implemented in different ways for different uses, I can't imagine colours/pixels could have a great number of implementation styles where different API's would have any reason to compete, and as such, it seems like a nice thing to standardise. Standardised colours would make it *much* easier for competing image libraries to interact. With standard colours, image libraries would tend to distinguish themselves in terms of memory management, data layout, image processing patterns and api, etc. Those are all valid cases for different designs, but I can't imagine any reason for distinct colour api's. Comprehensive colour-space management and minimum-loss encoding is a lot of work, and almost every implementation ignores facets of the puzzle that aren't obviously relevant. It would give a good foundation for other std.image related libraries to be built on top. I'm also working on a graphing lib, and that requires to output images. It would be *really* nice to support common image format readers/writers in the std library which need to handle pixel data. Thoughts? Please do. This was part of my goal with Devisualization.Image just without the phobos part.
Re: Phobos colour module?
On Thursday, 1 January 2015 at 06:47:14 UTC, ketmar via Digitalmars-d wrote: On Thu, 1 Jan 2015 16:38:32 +1000 Manu via Digitalmars-d wrote: Does it seem like something we should see added to phobos? i think that this will be a valuable addition. i really tired of copypasting various color model conversion code, for example, and i can never do that to the extent of "real" module. it will be great if Phobos will have tools for working with colors out of the box. Yes please.
Re: Phobos colour module?
On Thu, 1 Jan 2015 16:38:32 +1000 Manu via Digitalmars-d wrote: > Does it seem like something we should see added to phobos? i think that this will be a valuable addition. i really tired of copypasting various color model conversion code, for example, and i can never do that to the extent of "real" module. it will be great if Phobos will have tools for working with colors out of the box. signature.asc Description: PGP signature
