Aviso de privacidad: Este mensaje de correo electrónico puede contener información confidencial o legalmente protegida y está destinado únicamente para el uso del destinatario (s) previsto. Cualquier divulgación, difusión, distribución, copia o la toma de cualquier acción basada en la información aquí contenida está prohibida. Los correos electrónicos no son seguros y no se puede garantizar que estén libres de errores, ya que pueden ser interceptados, modificados, o contener virus. Cualquier persona que se comunica con nosotros por e-mail se considera que ha aceptado estos riesgos. Live Telecom no se hace responsable de los errores u omisiones de este mensaje y niega cualquier responsabilidad por daños derivados de la utilización del correo electrónico. Cualquier opinión y otra declaración contenida en este mensaje y cualquier archivo adjunto son de exclusiva responsabilidad del autor y no representan necesariamente las de la empresa.
El mar, 17 mar 2026 a la(s) 12:15 p.m., Lynne via ffmpeg-devel ( [email protected]) escribió: > On 17/03/2026 17:49, Christophe Gisquet wrote: > > Hi, > > > > Le mar. 17 mars 2026, 16:13, Lynne via ffmpeg-devel <ffmpeg- > > [email protected] <mailto:[email protected]>> a écrit : > > > > So I based this on the best lossy variant, which was Blackmagic RAW. > It > > does a partial debayering, but here, I keep the difference instead of > > throwing it away. Then I use the regular FFv1 prediction scheme to > > encode it. > > The prior art for the decomposition is "Reversible color transform > for > > Bayer color filter array images" by Iwahashi et. al. > > > > > > I imagine if complexity isn't super critical, but I have no idea about > > parents (which are critical for ffv1?), you could run a stronger > > decorrelation process. Maybe not PCA, but a simpler linear model (a la > > CfL/LM) built from running stats, or neighbourhood. > > > > But yes, for Bayer and/or RGB and/or higher-chroma-sampling images, that > > sounds like a great idea. > Definitely, I did mention this in my follow-up to Michael. We could -- > after all, custom RCT coefficients are still marked as unstable, so we > could rip out RCT with something much more aggressive. Vulkan would > definitely be able to handle much more aggressive searching. > > Since it would influence coding RGB and Bayer, I think that this is > something that we should explore after we have implemented Bayer to have > a benchmark for both. > _______________________________________________ > ffmpeg-devel mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ ffmpeg-devel mailing list -- [email protected] To unsubscribe send an email to [email protected]
