<div dir="ltr">Hi Johann, <div><br></div><div>There were a number of relevant points to unpack from your post, apologies if I don't hit all of them. </div><div><br></div><div>For EXR and PNG, I can easily see both sides. EXR has less library support in general and is less familiar than PNG. However, the biggest make-or-break argument that I see issupport for CMYKA (5 channels per pixel) which is impossible with PNG. EXR may have other benefits or complications, but from my perspective this is the decision maker. If we would like ORA format to be able to be used by print shops / for physically printed media, then in general it should have support for CMYKA. We can not convert from PNG to EXR (with 5 channels) without rounding errors which build up over saves. </div><div><br></div><div>I think we need to have a consensus on that decision before deciding if and how to be backwards compatible. </div><div><br></div><div>For effects I started a discussion a few threads up here: <a href="https://lists.freedesktop.org/archives/create/2020-May/005404.html">https://lists.freedesktop.org/archives/create/2020-May/005404.html</a></div><div><br></div><div>For vectors I would tentatively agree that the raster data should be provided along with the vector data, because the other option is to force every program to implement or source a full SVG rendering system. I don't know exactly how much of a stretch this is but I think even programs like Gimp were not suited well to it. </div><div><br></div><div>I think Alex already mentioned about affine transforms. Basically you start with one raster layer, which is always saved un-transformed. Then you apply the matrix of values multiplied over each pixel in that image to render the transformed version. By saving the transform as a matrix you preserve the ability to easily edit the original raster, which is the goal of many of these efforts (non destuctive edits). </div><div><br></div><div>-Paul</div></div>