Re: [Cellar] "raw" data from scanner

Jerome Martinez <> Thu, 26 April 2018 10:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F1B9C1200F1 for <>; Thu, 26 Apr 2018 03:00:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6XaiJ_qH7b-t for <>; Thu, 26 Apr 2018 03:00:50 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 3C19112708C for <>; Thu, 26 Apr 2018 03:00:50 -0700 (PDT)
Received: from (unknown []) by (Postfix) with ESMTP id 4C829D2410 for <>; Thu, 26 Apr 2018 12:00:47 +0200 (CEST)
Received: from [] ( []) (Authenticated sender: by (Postfix) with ESMTPSA id ADCA14400CD for <>; Thu, 26 Apr 2018 12:00:43 +0200 (CEST)
References: <r470Ps-10116i-3E6FE8CFD4314B82A7D3487B2CC4CBE6@Castor.local>
From: Jerome Martinez <>
Message-ID: <>
Date: Thu, 26 Apr 2018 12:00:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.7.0
MIME-Version: 1.0
In-Reply-To: <r470Ps-10116i-3E6FE8CFD4314B82A7D3487B2CC4CBE6@Castor.local>
Content-Type: multipart/alternative; boundary="------------6FA383FB9318841FA17C7F41"
Content-Language: en-GB
X-Ovh-Tracer-Id: 11767342878914777233
X-VR-SPAMCAUSE: gggruggvucftvghtrhhoucdtuddrgedtgedrleefgddvgecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfqggfjpdevjffgvefmvefgnecuuegrihhlohhuthemuceftddtnecu
Archived-At: <>
Subject: Re: [Cellar] "raw" data from scanner
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Codec Encoding for LossLess Archiving and Realtime transmission <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 26 Apr 2018 10:00:58 -0000

On 26/04/2018 11:57, Reto Kromer wrote:
> Jerome Martinez wrote:
>> e.g. with CineForm RAW, issue is to have a usable
>> decoder for such stream, it takes time to adapt the CineForm
>> RAW decoder source code to something usable for FFV1 encoder
>> input),
> I personally gave up this approach soon after the code has been
> released

This is something I don't like too, after having looked at the code.

>   and in my company we do actually "intercept" the
> sensor's data before they are encoded in something I don't like.

Whatever is the format, it may be great to have some samples (and 
description of the storage "format") so we can unblock
by providing proof it is OK.
Currently, it is a bit chicken and egg issue (I submitted a proposal in 
theory, but I have nothing for proving it is fine in practice, and looks 
like spec is expected before testing).

> I would like to encode directly into correct, standard, etc.
> FFV1 version N (possibly N = 4). That's my point. Sorry for not
> haven been clear!

IMO using a new colorspace_type is enough and does not mandate a new 
version, we could stay on v3 (lot of other formats don't upgrade their 
version when they add new "profiles") if we don't add complexity (e.g. 
my patch proposal add no complexity to the decoder, it use the same 
algorithm; if better compression with a different algorithm is found 
later, it could be in v4)