Why would those equations not make sense?? I literally looked the top two up on wikipedia. And the bottom one was reverse engineered from the ds decoder and I verified it to be accurate for this codec. I too think that converting to rgb is not the most elegant solution, but it would be better than just wrong colors I think.
Op di 16 mrt. 2021 08:55 schreef Paul B Mahol <one...@gmail.com>: > 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". _______________________________________________ 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".
