Subject: [Cbor] typed arrays for complex numbers

From: Gregory Allen <[email-masked]>
Date: Thu, 11 Jul 2019 18:24:29 -0500

I’m glad to see the proposal for typed homogeneous arrays in CBOR, and have a question.

How would one markup complex data? Similarly, how would one markup other compound types such as quaternion, RGB, or RGBA data?

Note that there is some disagreement out there as to approaches for this. NumPy defines new types for complex numbers (e.g. complex64). HDF5 describes complex numbers as structs containing re and im.

I believe that complex numbers are an important and widely used class of data for CBOR to be able to contain.

I could imaging a “complex” tag, that’s a modifier for a dataType, so that one could do:

    multi-dim([dim, complex(ta-float32le(bstr)) ])

However, that doesn’t scale well to having several different compound types such as those mentioned above.

What are your thoughts on containing this kind of data?

Thanks,
-Greg

Gregory E. Allen, PhD, Sr Engineering Scientist
Applied Research Laboratories: The University of Texas at Austin
512-835-3487

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 12 Jul 2019 02:23:23 +0200

> However, that doesn’t scale well to having several different compound types such as those mentioned above.

Well, it requires a new tag for each of these compound types, but if these are indeed different types, then tags are cheap (as long as they don’t have to come out of the 1+1 space :-).

So if this helps, we could indeed define tags (for complex, quaternion, octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, 3, 4 elements out of an array (tagged or classical CBOR).
(Well, RGB is a bit weird, because there are so many color spaces.  Maybe just have tags for three- and four-dimensional color spaces.)
Alternatively, supplying the group size separately maybe can do all of these at omce, but then cannot distinguish quaternions from RGBA or CMYK.

Grüße, Carsten

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Fri, 12 Jul 2019 10:17:07 -0400

On Fri, Jul 12, 2019 at 02:23:23 +0200, Carsten Bormann wrote:
> So if this helps, we could indeed define tags (for complex, quaternion,
> octonions, sedenions, RGB, RGBA) that extract groups of 2, 4, 8, 16, 3, 4
> elements out of an array (tagged or classical CBOR).
> (Well, RGB is a bit weird, because there are so many color spaces.  Maybe
> just have tags for three- and four-dimensional color spaces.)

I'm far from a color expert, but as far as I know even for RGB color spaces
the values aren't always stored in one order.  At the very least there are
RGBA and ARGB.

Currently my best idea amounts to:

	color(["RGB", [R1, G1, B1, R2, ...])
	color(["RGBA", [R1, G1, B1, A1, R2, ...])
	color(["CMYK", [C1, M1, Y1, K1, C2, ...])

I don't know if using a text string to identify the color component names
and order is an anti-pattern in CBOR but it is similar to the currency
related tags discussed some months ago.

This could even be extended to support planar formats (where the values for
each component are clumped together to allow better compression) and chroma
subsampling (where there aren't the same number of samples for each
component).  With either:

	color(["RGB", [R1, R2, ...], [G1, G2, ...], [B1, B2, ...])
	color(["YUV420", [Y1, Y2, ...], [U1, U2, ...], [V1, V2, ...])

or:

	color(["RGB", [R1, R2, ..., G1, G2, ..., B1, B2, ...])
	color(["YUV420", [Y1, Y2, ..., U1, U2, ..., V1, V2, ...])

I suppose the second would need to identify the number or ratio of values
for each component to support chroma subsampling, so the first would
probably be better.

Going down the rabbit hole of storing color data, there are also CCDs which
red/blue pixels.

Anyway, beware I know just enough about this to be dangerous :)  I'd
probably stay away from defining tags for colors until an actual expert
comes along.

Jeff.

> _______________________________________________
> CBOR mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cbor

-- 
My public PGP key can be found at https://www.josefsipek.net/pgp/

---

From: Gregory Allen <[email-masked]>
Date: Mon, 15 Jul 2019 09:55:21 -0500

Perhaps “complex” deserves a special tag because it’s so common, but it’s easy to see how a tag for each type of compound data doesn’t scale well.

Following Jeff’s line of reasoning could lead to something like structured data types in NumPy [https://docs.scipy.org/doc/numpy/user/basics.rec.html]. HDF5 supports similar constructs.

The idea is that one describes the type, and then an array can contain elements of the user-defined type. This can be used to describe blobs containing homogeneous arrays of arbitrary structures.

For example (from NumPy):

    cymk_type = [(‘c’, np.uint8), (‘y’, np.uint8), (‘m’, np.uint8), (‘k’, np.uint8)] # list of (name, type) pairs
    x = np.zeros([640, 480], dtype=cymk_type)

I didn’t propose this before because it’s obviously much greater in scope than adding a “complex” tag. It’s not even clear to me what approach I would want to take to add this to CBOR.

Thanks,
-Greg

> On Jul 12, 2019, at 9:17 AM, Josef 'Jeff' Sipek <[email-masked]> wrote:
>

---

From: Josef 'Jeff' Sipek <[email-masked]>
Date: Thu, 18 Jul 2019 09:51:18 -0400

On Mon, Jul 15, 2019 at 09:55:21 -0500, Gregory Allen wrote:
> Perhaps “complex” deserves a special tag because it’s so common,

My instinct is telling me that you are correct.

If someone ever comes up with a more generic way to store vectors in
arbitrary n-dimensional spaces, they can always say that complex numbers
should use this other tag.

> but it’s easy to see how a tag for each type of compound data doesn’t
> scale well.
> 
> Following Jeff’s line of reasoning could lead to something like structured
> data types in NumPy
> [https://docs.scipy.org/doc/numpy/user/basics.rec.html]. HDF5 supports
> similar constructs.
> 
> The idea is that one describes the type, and then an array can contain
> elements of the user-defined type. This can be used to describe blobs
> containing homogeneous arrays of arbitrary structures.
> 
> I didn’t propose this before because it’s obviously much greater in scope
> than adding a “complex” tag. It’s not even clear to me what approach I
> would want to take to add this to CBOR.

Interesting.  I'd definitely want to leave this to someone who knows more
about this / actually cares about this :)  (That may be you, for all I
know!)

Jeff.

-- 
You measure democracy by the freedom it gives its dissidents, not the
freedom it gives its assimilated conformists.
		- Abbie Hoffman