On Sat, Feb 28, 2015 at 1:50 AM, Niklas Haas <g...@nand.wakku.to> wrote:
> +static int png_get_gama(enum AVColorTransferCharacteristic trc, uint8_t *buf) > +{ > + double gamma; > + switch (trc) { > + case AVCOL_TRC_BT709: > + case AVCOL_TRC_SMPTE170M: > + case AVCOL_TRC_SMPTE240M: > + case AVCOL_TRC_BT1361_ECG: > + case AVCOL_TRC_BT2020_10: > + case AVCOL_TRC_BT2020_12: > + /* these share a segmented TRC, but gamma 1.961 is a close > + approximation, and also more correct for decoding content */ > + gamma = 1.961; > + break; > + case AVCOL_TRC_GAMMA22: > + case AVCOL_TRC_IEC61966_2_1: > + gamma = 2.2; > + break; > + case AVCOL_TRC_GAMMA28: > + gamma = 2.8; > + break; > + case AVCOL_TRC_LINEAR: > + gamma = 1.0; > + break; > + default: > + return 0; > + } > + > + AV_WB32_PNG(buf, 1.0 / gamma); > + return 1; > +} > + Co-incidentally I was thinking of submitting a patch to write the old QuickTime gama atom and most of this function would be useful if extracted to a common place (everything but the AV_WB32_PNG() as .mov's need a different scaling). Where should it go? libavutil? As part of it I would also allow manually specifying a specific value to encode on the command line, but I wondered about how to form the command line options... Case 1 User wants to write gamma based on TRC settings, using the above (now extracted) function. +write_gama on movflags? Case 2 User wants to specify the actual gamma on the command line Same as above, plus a -gamma <double> I'd suggest to require +write_gama on the command line as the gama atom is deprecated and should really be only needed for backwards compatibity/broken tools. Comments? Kevin _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel