Legacy ImageMagick Discussions Archive

Jusiponen,

good catch with the -resize, another magick trick in the bag, thank you. Never had issues with playing my panny's 1920x1080 (specified as such in a CPL's ScreenAspectRatio tag), though (tried on XDC G3 and Doremi). I'm avoiding scaling wherever I can.

Wrt audio: Yes, let's find a better way. sox comes to mind. For now I'm exporting broadcast wavs from ardour which is tedious.

Wrt sRGB gamma: It's (approximately) 2.2 and not, like my previous posting might be read, 1/2.2. The latter (0.4545...) would be used to (approximately) linearize sRGB material. Like

This seems relevant to the previous post about proper color handling when resizing. Magick recently brought this to my attention.

http://www.4p8.com/eric.brasseur/gamma.html

specifically http://www.4p8.com/eric.brasseur/gamma.html#ImageMagick

see also the link at the bottom of that page http://www.all-in-one.ee/%7Edersch/gamma/gamma.html

fmw42 wrote:This seems relevant to the previous post about proper color handling when resizing. Magick recently brought this to my attention.
http://www.4p8.com/eric.brasseur/gamma.html

Yes, this needs to get sorted out. My gut reaction is it's okay for imagemagick to not implicitly linearize because the source's gamma might be unknown. Then there's DPX which can carry gamma info in the metadata. What about other formats?

It'd be nice if there was a proper "-linearize_srgb" operator which would implement the correct sRGB gamma decoding (http://www.brucelindbloom.com/Eqn_RGB_to_XYZ.html).
In pseudocode (for the R channel): Guess it can be done with -fx and ternary conditional per channel? Trying ...

EDIT: this would be a proper sRGB linearization, I guess: See http://en.wikipedia.org/wiki/SRGB#Speci ... sformation for the math and an explanation for why 0.04045 is used instead of 0.03928.