Subject: Re: [Cellar] "raw" data from scanner

From: Reto Kromer <[email-masked]>
Date: Thu, 26 Apr 2018 11:57:48 +0200

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 and in my company we do actually "intercept" the
sensor's data before they are encoded in something I don't like.
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!

Best regards, Reto

---

From: Jerome Martinez <[email-masked]>
Date: Thu, 26 Apr 2018 12:00:44 +0200

On 26/04/2018 11:57, Reto Kromer wrote:
> released

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

>   and in my company we do actually "intercept" the

Whatever is the format, it may be great to have some samples (and 
description of the storage "format") so we can unblock
https://www.ietf.org/mail-archive/web/cellar/current/msg01401.html
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).

> FFV1 version N (possibly N = 4). That's my point. Sorry for not

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)