Re: [Cbor] typed arrays for complex numbers

Josef 'Jeff' Sipek <jeffpc@josefsipek.net> Fri, 12 July 2019 14:17 UTC

Return-Path: <jeffpc@josefsipek.net>
X-Original-To: cbor@ietfa.amsl.com
Delivered-To: cbor@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 301C2120119 for <cbor@ietfa.amsl.com>; Fri, 12 Jul 2019 07:17:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R0Hkivhf3gMy for <cbor@ietfa.amsl.com>; Fri, 12 Jul 2019 07:17:19 -0700 (PDT)
Received: from smtp.jeffnet.31bits.net (josefsipek.net [71.174.113.7]) by ietfa.amsl.com (Postfix) with ESMTP id 5A1F31200F3 for <cbor@ietf.org>; Fri, 12 Jul 2019 07:17:19 -0700 (PDT)
Received: from meili (unknown [172.27.0.163]) by smtp.jeffnet.31bits.net (Postfix) with ESMTPSA id C62B317D7A; Fri, 12 Jul 2019 14:17:17 +0000 (UTC)
Date: Fri, 12 Jul 2019 10:17:07 -0400
From: Josef 'Jeff' Sipek <jeffpc@josefsipek.net>
To: Carsten Bormann <cabo@tzi.org>
Cc: Gregory Allen <gallen@arlut.utexas.edu>, cbor@ietf.org
Message-ID: <20190712141659.GA1505@meili>
References: <15400EA6-DA5F-499E-B9A5-B98E0A6887CB@arlut.utexas.edu> <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <49F73FF9-1952-421E-9C0D-A9B2821FCEC7@tzi.org>
User-Agent: Mutt/1.11.4 (2019-03-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/cbor/juIL_joKIybFv47CpJ12FNuOu48>
Subject: Re: [Cbor] typed arrays for complex numbers
X-BeenThere: cbor@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Concise Binary Object Representation \(CBOR\)" <cbor.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/cbor>, <mailto:cbor-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/cbor/>
List-Post: <mailto:cbor@ietf.org>
List-Help: <mailto:cbor-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/cbor>, <mailto:cbor-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 12 Jul 2019 14:17:22 -0000

On Fri, Jul 12, 2019 at 02:23:23 +0200, Carsten Bormann wrote:
> On Jul 12, 2019, at 01:24, Gregory Allen <gallen@arlut.utexas.edu> wrote:
> > 
> > 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.
> 
> 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.)

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.

> 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
> 
> _______________________________________________
> CBOR mailing list
> CBOR@ietf.org
> https://www.ietf.org/mailman/listinfo/cbor

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