On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt <[email protected]> wrote:
> It's actually closer to normal yuv than ycocg. If you look at the > coefficients of normal yuv > r = y + 1.14v > g = y - 0.39u - 0.58v > b = y + 2.03u > > ycocg > r = y + co - cg > g = y + cg > b = y - co - cg > > the format used in actimagine > r = y + 2v > g = y - 0.5u - v > b = y + 2u > Something is very wrong with those equations. They do not have sense. Next time make sure to use real player like mpv, and set frame color_space to ycgco or ycocg. > You can see it's more like yuv than ycocg. That's also why currently the > decoded colors still look "alright". I think it wouldn't be a good idea to > use converted ref frames and then convert back as it would likely introduce > errors. But like you are saying, this coded is as far as I know, never used > for large frame sizes, so it shouldn't really be an issue to have an extra > frame and it prevents other problems. > > Op ma 15 mrt. 2021 21:42 schreef Lynne <[email protected]>: > > > Mar 15, 2021, 21:20 by [email protected]: > > > > > Good to know the order doesn't matter. In that case I should be able to > > use > > > it! > > > > > > I don't have any docs about the format because it's all proprietary, > but > > I > > > did some testing with the official codec for windows and the color > > > conversion I reverse engineered from the decoder used in ds games > > > r = y + (v << 1) > > > g = y - (u >> 1) - v > > > b = y + (u << 1) > > > results in colors that are equal to whatever I throw into the codec and > > > frames that are 1:1 equal to the output of the decoder included in the > > > windows codec. > > > > > > > That's looking really close to YCoCg. In fact it probably is just a > > variant of > > YCoCg. You should be able to convert between both with no loss of quality > > or rounding errors and just mark the output frame as being YUV with a > > YCoCg colorspace. The wikipedia page on YCoCg has RGB<->YCoCg > > conversions you can follow. > > > > > > > I suppose that I would just have to allocate an extra frame if I wanted > > to > > > do conversion to normal yuv colors. That frame would then be returned > and > > > the original frame would be put in the ref queue. > > > > > > > You could implement an inverse step when you use the reference frames, > > but for such a codec, where the frame size is going to be comparitively > > tiny, I think you can just get away quicker with copying and the > converting > > the copied frame, while keeping your ref frames as-is. > > _______________________________________________ > > ffmpeg-devel mailing list > > [email protected] > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > [email protected] with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > [email protected] > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > [email protected] with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list [email protected] https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email [email protected] with subject "unsubscribe".
