Legacy ImageMagick Discussions Archive

EWA-Lagrange looks like a less sharp EWA-Catroom and I prefer EWA-Lancozs3 and EWA-Mitchell over EWA-SincSinc2, how would be a good command line for kaiser?

Pictus wrote:but the windmill nobody likes the house bricks in the linear light version...

I prefer the linear light version because it is really what I saw at six feet away from the screen showing the original photo at 1:1.
And I actually hesitate calling the pattern "generated" by EWA-Catrom as "moire" because I was also seeing this pattern too.

I guess people do not like the linear version because we are all too used to the blurred sRGB downsizing by most previewers.

BTW, EWA-SincSinc3 and 4 are really interesting. Their excessive haloing is producing darkening/brightening artifacts only at some particular downsize ratios.

fmw42 wrote:

henrywho wrote:

henrywho wrote:The colors in Jinc4Sharpest.png are completely wrong.

No such problem if I download the png file and view it from my harddisk. It's weird.

Viewing may depend upon the viewing app and its interpretation of PNG rendering intent which has somewhat recently been changed to perceptual. Not sure if this is the issue or not.

I won't strip anymore, so that the Rendering intent is (hopefully) passed along with the image.
Note that even though Perceptual rendering intent is, in theory, the most reversible of the bunch, Dr. John Cupitt of VIPS/NIP2, formerly of the National Gallery and now with a medical imaging division of Imperial College, and my go-to person when I can't sort colour space questions on my own, will only use Relative if he has a choice because it's the one that's less likely to cause problems. It chops, but it chops "safely", and what's within the chopping block "stays more or less put".
This being said, "the world" uses Perceptual for consumer uses. (If I remember, Absolute is used a lot by professional printing shops in North America. Perceptual in Japan. "Professional printing" is not "the world".)

All the methods I tried so far, all linear light, produce faint diagonal light lines on "the" wall of the windmill image when reduced to 1024x1536. They are not really visible at the ratio used on the DSP Forums (1024 longest side, if I remember). And I have to pixel peep for them to stare me in the face. The methods are picking up diagonal high frequencies which are created by the layout of the bricks!

henrywho wrote:...
BTW, EWA-SincSinc3 and 4 are really interesting. Their excessive haloing is producing darkening/brightening artifacts only at some particular downsize ratios.

If they are the ones suffering the most from this, this immediately puts them in my "sucks" bin. (With little surprise or regret, as you probably know, given that Anthony has found that they produce negative weight sums when enlarging, which can be more or less explained with a back of the envelope calculation.)
Thank you very much for all your comments. Really informative.

I may not use png for my next batch of tests: http://hsivonen.iki.fi/png-gamma/.
Will there be howls of protest if I use stripped sRGB uncompressed TIFF?

P.S. Hmmm! Maybe I'll use ridiculous quality sRGB JPEG.

Pictus wrote:...
I am enjoying the sharpness of EWA Catrom...

I really don't like the "jaggies" in the EWA Catrom version of the windmill (maybe we should rename this test image "the brick wall", because it's the wonderful piece of not quite straight brickwork which we all argue about). (There are in Lanczos too, but less obvious.)
Just looking, I bet it's going to moire like crazy at some reduction ratios: The antialiasing is just not good enough. It's right at the edge of "in your face" moire.

Warning
It's going to take some convincing to make me put EWA Catrom or Sinc or Lagrange in my "good" bin.
I'm immensely prejudiced for back of the envelope/worst case scenario reasons.
And I'm personally biased toward more "neutral" schemes (and schemes that just "happen" to have my name).

Do you mean "-quality 99% -sampling-factor 1:1:1" ? I was always thinking if there is any JPEG library which takes advantage of 16-bit input to produce higher quality output at a smaller size (just like x264's Hi10P).

BTW, would you mind telling us the settings for JincJinc4Radius and JincJinc2Radius?

Pictus wrote:...good command line for kaiser?

viewtopic.php?f=2&t=20944&start=15#p84911 noting that for a while there was a bug w.r.t. setting the alpha (now called kaiser-beta) parameter, and that being able to set this parameter is a somewhat recent addition to ImageMagick, then rewind to the beginning of the thread.

Warning ImageMagick has been going through a period of rapid change w.r.t. image resizing and distorting and colorspace conversion in the last few months. (Do Anthony and Cristy ever sleep? I am very thankful---somewhat embarrassed, actually---that they've implemented so many of my feature requests in the midst of a major rewrite for ImageMagick version 7.)
Consequence: Either test methods that have worked for a long time, or use bleeding edge. I don't have the patience to always give code guaranteed to work even on a month old version of IM.

henrywho wrote:Do you mean "-quality 99% -sampling-factor 1:1:1"?

Exactly, but I'll stick to 8-bit.

henrywho wrote:I was always thinking if there is any JPEG library which takes advantage of 16-bit input to produce higher quality output at a smaller size (just like x264's Hi10P).

I'm not sure whether IM does it well (I think that IM has trouble with tiled TIFF, but I've not checked recently, and I tend to forget details like this), but I believe VIPS/NIP2 reliably produces 16-bit sRGB compressed striped or tiled TIFF, with a choice of compression method, including JPEG.
Also: libjpeg has gotten pretty fancy in recent years. If you use bleeding edge features, you may get somewhere. (16-bit images don't compress as well as 8-bit. Also: Competing with x264 is a very tall order. Wanna try WebP? Make sure to use a reasonably current WebP encoder: The early versions were not very good.)
(The above is off the top of my head. Please don't bash it too hard! Just set me straight. I would not be surprised if most of it is wrong. Too busy to double check.)
Also note that I started working on "how to use JPEG compression for maximum profit by manipulating quantization tables and progressive encoding" but got sidetracked. (I still owe some documentation/examples to Cristy. Argh!)

henrywho wrote:BTW, would you mind telling us the settings for JincJinc4Radius and JincJinc2Radius?

Radius 2: Radius 3: Radius 4: I have high hopes for these schemes, esp. the radius 3 one.

I'll just stick with sRGB PNG. Whatever colour inaccuracies there are because of PNG/image viewer issues, they'll be the same across the board, at least for the results I produce myself with ImageMagick.

FYI, the original "windmill"'s metadata specifies the rendering intent to be "0" = Perceptual.
ImageMagick does not embed Rendering Intent data in pngs. Make sure your viewer "imports" the upcoming pngs with Perceptual sRGB, otherwise comparing colours between the original and the downsized versions does not make sense.
If you can't make your image viewer behave
(Recent? I don't remember if you could import pngs with a profile in versions more than a few months old. Just try it. I think it would import, but not with an embedded one; we don't need this feature anyway.) NIP2 (the GUI of the VIPS library) allows you to explicitly import an image with a specified profile (choose sRGB) and rendering intent (choose Perceptual). Go to Toolkits -> Colour -> ICC -> Import and then choose Perceptual and sRGB. The sRGB profile that comes with NIP2 is decent quality v2 (you can point it to a profile you provide, if you prefer). NIP2 installs on most OSes: http://www.vips.ecs.soton.ac.uk/index.p ... =Supported. I believe it installs its own version of ImageMagick on some OSes, which may be useful if you have trouble installing ImageMagick on your OS: Just use the one that comes with NIP2. (Obviously this comment does not apply to Linux.) You can actually use NIP2 as a scriptable GUI for ImageMagick: http://libvips.blogspot.ca/2011/06/usin ... -nip2.html. The number of ported ImageMagick operations is small, but minimal coding allows one to add more.