Lanczos: Tensor, EWA, HDRI, Q, ugh?

[Marsu42]

Simple /me is trying to downsize-sharpen my natural photography shots (so no test patterns here and some minor quirks won't show, but I do want fast performance for batch processing). After trying to rtfm I'm still left with a few question, I'd be delighted for some insight.

1. -filter Lanczos: I've read this requires a HDRI build?
2. -filter LanczosRadius positively requires EWA (i.e. -distort)?

Thing is: Everything work just fine with my non-hdri im build and tensor (i.e. -resize) ... and with a quick comparison I cannot really see a difference. Or am I missing something important and certain doom is just 'round the corner ?

3. -filter LanczosRadius: Can I add -define filter:blur=0.88549061701764 like with regular Lanczos or does this destroy the filter balance?
4. With a Q8 IM build: Should/can I use linear light for tensor and/or EWA (i.e. -colorspace RGB -yadayadayada -colorspace sRGB)?

Thanks!

[snibgo]

4. With a Q8 IM build: Should/can I use linear light for tensor and/or EWA (i.e. -colorspace RGB -yadayadayada -colorspace sRGB)?

You can, but I think it's a bad idea. Any gamma shift with integer IM will reduce the number of unique values. The round-trip to linear and back reduces 256 possible values to 183. Most of the loss is in the shadows: value that were different get squished together. For example, values from 0 to 28 (out of 255) get squished into just four values (being 0, 13, 22 and 28).

Whether this matters depends, of course, on the nature of the pictures, what they are for and so on.

[Marsu42]

4. With a Q8 IM build: Should/can I use linear light for tensor and/or EWA (i.e. -colorspace RGB -yadayadayada -colorspace sRGB)?

For example, values from 0 to 28 (out of 255) get squished into just four values (being 0, 13, 22 and 28).

This definitely is not what I want (or probably anyone). Unfortunately I only realize by now, after giving away shots processed this way. It's not like this information jumps at you even rtfm'ing... on http://www.imagemagick.org/script/comma ... colorspace it just states that "Note "the scRGB colorspace requires HDRI support otherwise it behaves just like linear RGB"".

Imho there should be a big fat warning in the IM output (and on the web site) when doing -colorspace RGB with Q8 ... any dev reading this or should I bump it to the dev forum? Or is it just me?

I hope someone can provide some help on questions 1-3 from above

[snibgo]

You are welcome to make any documentation (or other development) suggestions you want. I realised that I wanted so much new documentation that it was easier to write it myself. Hence my website http://im.snibgo.com

When using integer IM (or any other software): any shift, up or down, inevitably squishes some values together. With Q16 the sRGB -> RGB -> sRGB roundtrip also squishes values: the 65536 possible values are reduced to 46719; the bottom 10% of values (0 to 6554) are squished into just 657 values. I would not expect this Q16 squishing (or "banding") to be visible. It isn't generally a problem, if you work in Q16 or larger, and only do the round-trip once.

The squishing does not occur with HDRI versions of IM.

If I could help with your other questions, I would.

EDIT: Incidentally, we can graph this banding for the Q8 case. The x-axis is the input, the y-axis the output. The output values are also shown visually beneath the graph, and I can see the banding in the darkest values. (Visibility will depend on monitor settings.)

[Marsu42]

You are welcome to make any documentation (or other development) suggestions you want. I realised that I wanted so much new documentation that it was easier to write it myself. Hence my website http://im.snibgo.com

Thanks, I know the site and already got great snippets from it - thanks a lot, providing working actual samples is more intuitive than the pure im docs for me. It's just that the Q8/Q16/HDRI problem is so blatant and even after rtfm'ing for quite a while I didn't realize, maybe it's not just me but other ppl didn't get it, too.

If I could help with your other questions, I would.

No doubt, but hopefully you're not the only participant around here . However, you not knowing the answers shows that these resize algorithms and how to get the best results are really tricky, so I don't need to feel all that bad about being baffled. I read somewhere that confusion is the natural state after reading about these matters, and it takes years and writing serveral phd theses to get a grip on 'em :->

http://snibgo.com/imforums/s8_squish_glc.png

This is a great demonstration that this should be really avoided, I'll make said suggestion over in the dev sub-forum.