On Mon, Mar 15, 2021 at 10:02 PM Florian Nouwt <fnou...@gmail.com> 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 <d...@lynne.ee>: > > > Mar 15, 2021, 21:20 by fnou...@gmail.com: > > > > > 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 > > ffmpeg-devel@ffmpeg.org > > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > > > To unsubscribe, visit link above, or email > > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". > _______________________________________________ > ffmpeg-devel mailing list > ffmpeg-devel@ffmpeg.org > https://ffmpeg.org/mailman/listinfo/ffmpeg-devel > > To unsubscribe, visit link above, or email > ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe". _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
