Topic: A free high quality resampling tool for ImageMagick users (Read 252444 times)

Bart_van_der_Wolf · « **on:** July 17, 2014, 11:47:12 am »

Hi folks,

As a result of a discussion in another thread in this forum, and with permission of Nicolas Robidoux who suggested the prodedure, you are free to download and use the attached ImageMagick resampling script in a ZIP archive. NOTE, an updated version is available here.

It is formatted as a Windows batch file that uses ImageMagick for the actual number crunching, and it allows to drag and drop an image on the batch-file icon which can be situated on the desktop or in a folder. It will ask the user for a percentage value by which to resize the image pixel dimensions. Do *not* enter a percentage sign, or any other non-numerical input, just a number. A number larger than 100 will enlarge the image, a number smaller than 100 will reduce the image size. So e.g. just entering 25 will reduce the linear pixel dimensions to one quarter (25%), and 300 will triple the linear pixel dimensions (300%). Decimal separators, e.g. 33.33333 for a reduction to a third of the dimensions are allowed (regional OS settings may allow other separators, I'm not sure).

For ease of use in a Windows computer system, the file can also be added to the User's 'SendTo' file location (e.g. 'C:\Users\YOURNAME\AppData\Roaming\Microsoft\Windows\SendTo' for Windows 7), which will then allow to right mouse-click on an image file in the File Explorer and send it to the script to be processed by ImageMagick (which is assumed to be already installed on the user's computer).

The Resampled image file with a PNG file type and extension will be placed in the same folder or directory as the original file, with a postfix to the filename that indicates the resampling percentage that was used. The script currently will *not* ask if overwriting with that (assumed new) filename is allowed, should it already exist (which is unlikely anyway, but you are now assumed to have been warned!).

Currently the script assumes input files with an sRGB gamma and colorspace. This is something that can be changed in the file itself, or may be added to a future edition as a selection option.

Which brings us to the following. This file is the product of a free exchange of ideas on various fora. People are encouraged to add and share improvements, and versions adapted to other operating systems for which ImageMagick is available, such as UNIX and Mac OS.

Feature requests may be considered, but implementing them is merely a request to volunteers who may or may not wish to spend they spare free time to actually implement and test such modifications. Consider this to be an open collaborative project, so your input is also valued.

Use at your own peril or for enjoyment.

Cheers,
Bart

P.S. This is a works in progress, and the initial file can be improved I'm sure. Feel free to tell me how ...

NicolasRobidoux · « **Reply #1 on:** July 17, 2014, 04:33:53 pm »

A more radical approach is to use a pair of gammas, that is, replacing, for example, the linear RGB result (used to compute the luminance alpha channel) by the result of ... -gamma .3333333333333333 -filter LanczosRadius -distort Resize 800% -gamma 3 when blending.
Somehow, I think that sticking to linear light is likely to be better for the "not too much light halo" component, but who knows?
P.S. I just gave a quick and very dirty try to a version in which instead of using luminance I used the average of the through gamma 1/3 and the through gamma 3 results, and the nice thing about it is that it restores the "black/white symmetry". I'm not saying this is the best way to do things, just that it did not turn out badly. HDRI (floating point computation toolchain) may be necessary here. Not sure.

Bart_van_der_Wolf · « **Reply #2 on:** July 17, 2014, 04:49:26 pm »

Quote from: NicolasRobidoux on July 17, 2014, 04:33:53 pm

A more radical approach is to use a pair of gammas, that is, replacing, for example, the linear RGB result (used to compute the luminance alpha channel) by the result of ... -gamma .3333333333333333 -filter LanczosRadius -distort Resize 800% -gamma 3 when blending.
Somehow, I think that sticking to linear light is likely to be better for the "not too much light halo" component, but who knows?

Indeed Nicolas, that idea had crossed my mind. If it works for one layer, it should also work for the other layer, with opposite gamma boosts, QED.

I will explore that alternative after looking a bit more at some potential optimizations of the current code. And since the results are that well behaved as far as haloing is concerned, sharpening the result is also a possible option to add in a multi-line script. Having a working script will make implementing such alternatives almost trivial.

I've also tried a 'null' conversion, 100 percent same size resampling, which produced only minimal differences in high spatial frequency areas. We'd have to be careful to keep such neutral behavior intact. Need to test that some more.

Cheers,
Bart

fdisilvestro · « **Reply #3 on:** July 17, 2014, 06:58:55 pm »

Hi Bart,

Thanks for sharing the script. I have followed with interest the other thread and will be trying this over the weekend.
I have a couple of questions related to the script (I'm on the road so I can't test for myself now):

I see that you convert to 16 bits, but does the input file has to be in a specific format or will it work with tiff, jpg or png?

When you mention sRGB gamma, are you referring to sRGB TRC or an approximate gamma (e.g. 2.2)?

From what I can follow in the script, you separate the RGB channels and then recombine adding the calculated alpha channel.
If the script is modified, will it work for monochrome images (not RGB, only gray channel)? Pardon my ingenuity, but I'm thinking of skipping the channel separation part, computing the alpha channel and then recombine the gray with the alpha.

Regards

NicolasRobidoux · « **Reply #4 on:** July 18, 2014, 03:56:45 am »

Bart:

I have high hopes that something good can be squeezed of this research direction.

1) The reason for using "a pair of opposite gamma spaces" is to restore some black/white symmetry. I think that, however, the alpha should then be computed from either some sort of average of the two results or from linear light, in which case there would be three resampled images used to recombine: through RGB gamma 3 (for example), through RGB gamma 1/3, and linear RGB (gamma 1). These thoughts are a bit rough. Maybe one should work in a pair of direct/reverse video after normalizing the input image, then de-normalizing? Assuming the normalization anchors things at the black and white points (roughly), this would definitely restore black/white symmetry. (Quickly brainstorming, here.)

Poking really quickly into the first idea above, however, one would need a very accurate floating point toolchain to pull off an initial -gamma .3333333333333. Not sure, so this is more a "watch for this" than a true "jump up and down warning". But I'm a bit concerned that Q16 is not enough.

Mixing linear with gamma 3 sounds like a reasonable practical approach. But it definitely does not respect black/white symmetry.

2) EWA LanczosRadius is not interpolatory. Unless you explicitly used a hard wired "null" operation, there will be a difference when do "no-op" resampling. In practice, this difference could be argued to be a good thing (with EWA LanczosSharpest 4, for example). The real question is whether the final answer differs significantly from an infinite precision version of the result. I'm just making sure here, that you know (the reasonable assumption, namely that you do know, can be dangerous) that there are two sources for deviation from the original when resizing to the exact same dimensions: round off error and the fact that the filter actually does some filtering in all cases.

3) Fred Weinhaus has started optimizing the code further and poking around. We'll post things in the IM forums as soon as I've had time to check things over and organize results (and my thoughts) into something halfway intelligible.

Bart_van_der_Wolf · « **Reply #5 on:** July 18, 2014, 03:57:17 am »

Quote from: FranciscoDisilvestro on July 17, 2014, 06:58:55 pm

Hi Bart,

Thanks for sharing the script. I have followed with interest the other thread and will be trying this over the weekend.
I have a couple of questions related to the script (I'm on the road so I can't test for myself now):

I see that you convert to 16 bits, but does the input file has to be in a specific format or will it work with tiff, jpg or png?

Hi Frank,

Good question.

In principle ImageMagick supports a whole lot of file formats. Here are the ones it reports on my Microsoft Windows [Version 6.1.7601] installation:

>identify -list format
   Format Module Mode Description
-------------------------------------------------------------------------------
   3FR DNG r-- Hasselblad CFV/H3D39II
   A* RAW rw+ Raw alpha samples
   AAI* AAI rw+ AAI Dune image
   AI PDF rw- Adobe Illustrator CS2
   ART* ART rw- PFS: 1st Publisher Clip Art
   ARW DNG r-- Sony Alpha Raw Image Format
   AVI MPEG r-- Microsoft Audio/Visual Interleaved
   AVS* AVS rw+ AVS X image
   B* RAW rw+ Raw blue samples
   BGR* BGR rw+ Raw blue, green, and red samples
   BGRA* BGR rw+ Raw blue, green, red, and alpha samples
   BIE* JBIG rw- Joint Bi-level Image experts Group interchange format
(1.6)
   BMP* BMP rw- Microsoft Windows bitmap image
   BMP2* BMP -w- Microsoft Windows bitmap image (V2)
   BMP3* BMP -w- Microsoft Windows bitmap image (V3)
   BRF* BRAILLE -w- BRF ASCII Braille format
   C* RAW rw+ Raw cyan samples
   CAL* CALS rw- Continuous Acquisition and Life-cycle Support Type 1
   Specified in MIL-R-28002 and MIL-PRF-28002
   CALS* CALS rw- Continuous Acquisition and Life-cycle Support Type 1
   Specified in MIL-R-28002 and MIL-PRF-28002
   CANVAS* XC r-- Constant image uniform color
  CAPTION* CAPTION r-- Caption
   CIN* CIN rw- Cineon Image File
   CIP* CIP -w- Cisco IP phone image format
   CLIP* CLIP rw+ Image Clip Mask
CLIPBOARD* CLIPBOARD rw- The system clipboard
   CMYK* CMYK rw+ Raw cyan, magenta, yellow, and black samples
   CMYKA* CMYK rw+ Raw cyan, magenta, yellow, black, and alpha samples
   CR2 DNG r-- Canon Digital Camera Raw Image Format
   CRW DNG r-- Canon Digital Camera Raw Image Format
   CUR* CUR rw- Microsoft icon
   CUT* CUT r-- DR Halo
   DCM* DCM r-- Digital Imaging and Communications in Medicine image
   DICOM is used by the medical community for images like X-rays. The
   specification, "Digital Imaging and Communications in Medicine
   (DICOM)", is available at http://medical.nema.org/. In particular,
   see part 5 which describes the image encoding (RLE, JPEG, JPEG-LS),
   and supplement 61 which adds JPEG-2000 encoding.
   DCR DNG r-- Kodak Digital Camera Raw Image File
   DCX* PCX rw+ ZSoft IBM PC multi-page Paintbrush
   DDS* DDS rw+ Microsoft DirectDraw Surface
   DFONT* TTF r-- Multi-face font package (Freetype 2.5.3)
   DJVU* DJVU --- Déjà vu
   See http://www.djvuzone.org/ for details about the DJVU format. The
   DJVU 1.2 specification is available there and at
   ftp://swrinde.nde.swri.edu/pub/djvu/documents/.
   DNG DNG r-- Digital Negative
   DOT DOT --- Graphviz
   DPS DPS --- Display Postscript Interpreter
   DPX* DPX rw- SMPTE 268M-2003 (DPX 2.0)
   Digital Moving Picture Exchange Bitmap, Version 2.0.
   See SMPTE 268M-2003 specification at http://www.smtpe.org

   DXT1* DDS rw+ Microsoft DirectDraw Surface
   DXT5* DDS rw+ Microsoft DirectDraw Surface
   EMF WMF r-- Windows Enhanced Meta File
   EPDF PDF rw- Encapsulated Portable Document Format
   EPI PS rw- Encapsulated PostScript Interchange format
   EPS PS rw- Encapsulated PostScript
   EPS2* PS2 -w- Level II Encapsulated PostScript
   EPS3* PS3 -w+ Level III Encapsulated PostScript
   EPSF PS rw- Encapsulated PostScript
   EPSI PS rw- Encapsulated PostScript Interchange format
   EPT EPT rw- Encapsulated PostScript with TIFF preview
   EPT2 EPT rw- Encapsulated PostScript Level II with TIFF preview
   EPT3 EPT rw+ Encapsulated PostScript Level III with TIFF preview
   ERF DNG r-- Epson RAW Format
   EXR EXR --- High Dynamic-range (HDR)
   FAX* FAX rw+ Group 3 FAX
   FAX machines use non-square pixels which are 1.5 times wider than
   they are tall but computer displays use square pixels, therefore
   FAX images may appear to be narrow unless they are explicitly
   resized using a geometry of "150x100%".

   FITS* FITS rw- Flexible Image Transport System
   FPX FPX --- FlashPix Format
  FRACTAL* PLASMA r-- Plasma fractal image
   FTS* FTS rw- Flexible Image Transport System
   G* RAW rw+ Raw green samples
   G3* FAX rw- Group 3 FAX
   GIF* GIF rw+ CompuServe graphics interchange format
   GIF87* GIF rw- CompuServe graphics interchange format (version 87a)
GRADIENT* GRADIENT r-- Gradual linear passing from one shade to another
   GRAY* GRAY rw+ Raw gray samples
   GROUP4* TIFF rw- Raw CCITT Group4
   GV DOT --- Graphviz
   HALD* r-- Identity Hald color lookup table image
   HDR* HDR rw+ Radiance RGBE image format
HISTOGRAM* HISTOGRAM -w- Histogram of the image
   HRZ* HRZ rw- Slow Scan TeleVision
   HTM* HTML -w- Hypertext Markup Language and a client-side image map

   HTML* HTML -w- Hypertext Markup Language and a client-side image map

   ICB* TGA rw- Truevision Targa image
   ICO* ICON rw+ Microsoft icon
   ICON* ICON rw- Microsoft icon
   INFO INFO -w+ The image format and characteristics
   INLINE* INLINE r-- Base64-encoded inline images
   IPL* IPL rw+ IPL Image Sequence
   ISOBRL* BRAILLE -w- ISO/TR 11548-1 format
   J2C* JP2 rw- JPEG-2000 Code Stream Syntax (2.1.0)
   J2K* JP2 rw- JPEG-2000 Code Stream Syntax (2.1.0)
   JBG* JBIG rw+ Joint Bi-level Image experts Group interchange format
(1.6)
   JBIG* JBIG rw+ Joint Bi-level Image experts Group interchange format
(1.6)
   JNG* PNG rw- JPEG Network Graphics
   See http://www.libpng.org/pub/mng/ for details about the JNG
   format.
   JNX* JNX r-- Garmin tile format
   JP2* JP2 rw- JPEG-2000 File Format Syntax (2.1.0)
   JPC* JP2 rw- JPEG-2000 Code Stream Syntax (2.1.0)
   JPEG* JPEG rw- Joint Photographic Experts Group JFIF format (80)
   JPG* JPEG rw- Joint Photographic Experts Group JFIF format (80)
   JPT* JP2 rw- JPEG-2000 File Format Syntax (2.1.0)
   JSON JSON -w+ The image format and characteristics
   K* RAW rw+ Raw black samples
   K25 DNG r-- Kodak Digital Camera Raw Image Format
   KDC DNG r-- Kodak Digital Camera Raw Image Format
   LABEL* LABEL r-- Image label
   M* RAW rw+ Raw magenta samples
   M2V MPEG rw+ MPEG Video Stream
   M4V MPEG rw+ Raw MPEG-4 Video
   MAC* MAC r-- MAC Paint
   MAP* MAP rw- Colormap intensities and indices
   MASK* MASK rw+ Image Clip Mask
   MAT MAT rw+ MATLAB level 5 image format
   MATTE* MATTE -w+ MATTE format
   MEF DNG r-- Mamiya Raw Image File
   MIFF* MIFF rw+ Magick Image File Format
   MNG* PNG rw+ Multiple-image Network Graphics (libpng 1.6.10)
   See http://www.libpng.org/pub/mng/ for details about the MNG
   format.
   MONO* MONO rw- Raw bi-level bitmap
   MOV MPEG rw+ MPEG Video Stream
   MP4 MPEG rw+ MPEG-4 Video Stream
   MPC* MPC rw+ Magick Persistent Cache image format
   MPEG MPEG rw+ MPEG Video Stream
   MPG MPEG rw+ MPEG Video Stream
   MRW DNG r-- Sony (Minolta) Raw Image File
   MSL* MSL rw+ Magick Scripting Language
   MSVG SVG rw+ ImageMagick's own SVG internal renderer
   MTV* MTV rw+ MTV Raytracing image format
   MVG* MVG rw- Magick Vector Graphics
   NEF DNG r-- Nikon Digital SLR Camera Raw Image File
   NRW DNG r-- Nikon Digital SLR Camera Raw Image File
   NULL* NULL rw- Constant image of uniform color
   O* RAW rw+ Raw opacity samples
   ORF DNG r-- Olympus Digital Camera Raw Image File
   OTB* OTB rw- On-the-air bitmap
   OTF* TTF r-- Open Type font (Freetype 2.5.3)
   PAL* UYVY rw- 16bit/pixel interleaved YUV
   PALM* PALM rw+ Palm pixmap
   PAM* PNM rw+ Common 2-dimensional bitmap format
   PANGO* PANGO r-- Pango Markup Language (Pangocairo 1.36.0)
  PATTERN* PATTERN r-- Predefined pattern
   PBM* PNM rw+ Portable bitmap format (black and white)
   PCD* PCD rw- Photo CD
   PCDS* PCD rw- Photo CD
   PCL PCL rw+ Printer Control Language
   PCT* PICT rw- Apple Macintosh QuickDraw/PICT
   PCX* PCX rw- ZSoft IBM PC Paintbrush
   PDB* PDB rw+ Palm Database ImageViewer Format
   PDF PDF rw+ Portable Document Format
   PDFA PDF rw+ Portable Document Archive Format
   PEF DNG r-- Pentax Electronic File
   PES* PES r-- Embrid Embroidery Format
   PFA* TTF r-- Postscript Type 1 font (ASCII) (Freetype 2.5.3)
   PFB* TTF r-- Postscript Type 1 font (binary) (Freetype 2.5.3)
   PFM* PFM rw+ Portable float format
   PGM* PNM rw+ Portable graymap format (gray scale)
   PICON* XPM rw- Personal Icon
   PICT* PICT rw- Apple Macintosh QuickDraw/PICT
   PIX* PIX r-- Alias/Wavefront RLE image format
   PJPEG* JPEG rw- Joint Photographic Experts Group JFIF format (80)
   PLASMA* PLASMA r-- Plasma fractal image
   PNG* PNG rw- Portable Network Graphics (libpng 1.6.10)
   See http://www.libpng.org/ for details about the PNG format.
   PNG00* PNG rw- PNG inheriting bit-depth and color-type from original

   PNG24* PNG rw- opaque or binary transparent 24-bit RGB (zlib 1.2.7)
   PNG32* PNG rw- opaque or transparent 32-bit RGBA
   PNG48* PNG rw- opaque or binary transparent 48-bit RGB
   PNG64* PNG rw- opaque or transparent 64-bit RGBA
   PNG8* PNG rw- 8-bit indexed with optional binary transparency
   PNM* PNM rw+ Portable anymap
   PPM* PNM rw+ Portable pixmap format (color)
  PREVIEW* PREVIEW -w- Show a preview an image enhancement, effect, or f/x
   PS PS rw+ PostScript
   PS2* PS2 -w+ Level II PostScript
   PS3* PS3 -w+ Level III PostScript
   PSB* PSD rw+ Adobe Large Document Format
   PSD* PSD rw+ Adobe Photoshop bitmap
   PTIF* TIFF rw+ Pyramid encoded TIFF
   PWP* PWP r-- Seattle Film Works
   R* RAW rw+ Raw red samples
RADIAL-GRADIENT* GRADIENT r-- Gradual radial passing from one shade to anothe
r
   RAF DNG r-- Fuji CCD-RAW Graphic File
   RAS* SUN rw+ SUN Rasterfile
   RGB* RGB rw+ Raw red, green, and blue samples
   RGBA* RGB rw+ Raw red, green, blue, and alpha samples
   RGBO* RGB rw+ Raw red, green, blue, and opacity samples
   RGF* RGF rw- LEGO Mindstorms EV3 Robot Graphic Format (black and w
hite)
   RLA* RLA r-- Alias/Wavefront image
   RLE* RLE r-- Utah Run length encoded image
   RMF DNG r-- Raw Media Format
   RW2 DNG r-- Panasonic Lumix Raw Image
   SCR* SCR r-- ZX-Spectrum SCREEN$
SCREENSHOT* SCREENSHO r-- Screen shot
   SCT* SCT r-- Scitex HandShake
   SFW* SFW r-- Seattle Film Works
   SGI* SGI rw+ Irix RGB image
   SHTML* HTML -w- Hypertext Markup Language and a client-side image map

SPARSE-COLOR* TXT -w+ Sparse Color
   SR2 DNG r-- Sony Raw Format 2
   SRF DNG r-- Sony Raw Format
  STEGANO* STEGANO r-- Steganographic image
   SUN* SUN rw+ SUN Rasterfile
   SVG SVG rw+ Scalable Vector Graphics (RSVG 2.40.1)
   SVGZ SVG rw+ Compressed Scalable Vector Graphics (RSVG 2.40.1)
   TEXT* TXT rw+ Text
   TGA* TGA rw- Truevision Targa image
THUMBNAIL* THUMBNAIL -w+ EXIF Profile Thumbnail
   TIFF* TIFF rw+ Tagged Image File Format (LIBTIFF, Version 4.0.3)
   TIFF64* TIFF rw- Tagged Image File Format (64-bit) (LIBTIFF, Version 4
.0.3)
   TILE* TILE r-- Tile image with a texture
   TIM* TIM r-- PSX TIM
   TTC* TTF r-- TrueType font collection (Freetype 2.5.3)
   TTF* TTF r-- TrueType font (Freetype 2.5.3)
   TXT* TXT rw+ Text
   UBRL* BRAILLE -w- Unicode Text format
   UIL* UIL -w- X-Motif UIL table
   UYVY* UYVY rw- 16bit/pixel interleaved YUV
   VDA* TGA rw- Truevision Targa image
   VICAR* VICAR rw- VICAR rasterfile format
   VID* VID rw+ Visual Image Directory
   VIFF* VIFF rw+ Khoros Visualization image
   VIPS* VIPS rw+ VIPS image
   VST* TGA rw- Truevision Targa image
   WBMP* WBMP rw- Wireless Bitmap (level 0) image
   WEBP* WEBP rw- WebP Image Format (libwebp 0.4.0 (0202))
   WMF WMF r-- Windows Meta File
   WMV MPEG rw+ Windows Media Video
   WPG* WPG r-- Word Perfect Graphics
   X3F DNG r-- Sigma Camera RAW Picture File
   XBM* XBM rw- X Windows system bitmap (black and white)
   XC* XC r-- Constant image uniform color
   XCF* XCF r-- GIMP image
   XPM* XPM rw- X Windows system pixmap (color)
   XPS XPS r-- Microsoft XML Paper Specification
   XV* VIFF rw+ Khoros Visualization image
   Y* RAW rw+ Raw yellow samples
   YCbCr* YCbCr rw+ Raw Y, Cb, and Cr samples
   YCbCrA* YCbCr rw+ Raw Y, Cb, Cr, and alpha samples
   YUV* YUV rw- CCIR 601 4:1:1 or 4:2:2

* native blob support
r read support
w write support
+ support for multiple images

However, as you know, e.g. TIFF is a flexible format that can contain complex image data, including e.g. Photoshop Layers. IM uses the public LIBTIFF, Version 4 library to decode TIFFs. It therefore depends on others how well that works.

In my experience, that can cause confusion in the interpretation, and ImageMagick can report TAG errors as a result. It may even abort operation. I want to explore that further, to either have the IM code adjusted or find another way around it, to take away the hassle for users. PNG, and JPEG, and GIF seem to convert withot issues, and probably SVG's as well although that may require additional open-source resources. The IM documentation is constantly being updated.

To prevent such issues, one can try using a flattened version of the TIFF, or export it as a PNG (16-b/ch PNGs are fully supported, and produce relatively compact files). While inconvenient, we are after all talking about a specific targeted operation such as preparation for web-publishing. What's more, scripts can be adjusted to do batch processing of all files in subdirectories (even recursive), so one can prepare large volumes of flattened files in advance in their own subdirectories for unattended processing of multiple output sizes can be created, e.g. thumbnails and web display size and mobile device display size, all in their own subdirectories. All it takes is a bit of coding in an easy batch script language.

It may also be a good thing to investigate/test the use of ImageMagick's own MIFF file format, instead of the current PNGs since it seems to also retain color profile conversions.

Quote

When you mention sRGB gamma, are you referring to sRGB TRC or an approximate gamma (e.g. 2.2)?

I have to go by the documented description of that IM option. The sRGB colorspace conversion option (-colorspace) is described as:

Quote

sRGB
if R ≤ .0.0031308 then Rs=R/12.92 else Rs=1.055 R ^ (1.0 / 2.4) ? 0.055
if G ≤ .0.0031308 then Gs=B/12.92 else Gs=1.055 R ^ (1.0 / 2.4) ? 0.055
if B ≤ .0.0031308 then Bs=B/12.92 else Bs=1.055 R ^ (1.0 / 2.4) ? 0.055

So that would be a correct sRGB TRC adjustment with linear slope shadow detail based on linear RGB.

Quote

From what I can follow in the script, you separate the RGB channels and then recombine adding the calculated alpha channel.

Correct. The current alpha channel calculation uses the Gray colorspace (Gray = 0.298839*R+0.586811*G+0.114350*B) conversion. But that is just one of many possible alpha channel creations. One could even add a Sigmoidal S-curve to the alpha channel, should that provide better blending between the other layers (one with 'shadow halos' and the other with 'highlight halos)'. It's flexible enough to optimize any way one desires.

Quote

If the script is modified, will it work for monochrome images (not RGB, only gray channel)? Pardon my ingenuity, but I'm thinking of skipping the channel separation part, computing the alpha channel and then recombine the gray with the alpha.

Exactly what I was looking for, a way of avoiding the channel separation and recombination, and 'simply' adding the Alpha channel. That might require promoting a single channel file to a 4 channel RGBA file, with identical RGB channels. This has yet to be tested.

Thanks for thinking along.

Cheers,
Bart

NicolasRobidoux · « **Reply #6 on:** July 18, 2014, 04:16:43 am »

Courtesy of Fred Weinhaus, first pass (shell script)

# setup arguments

infile="input_small.png"
scale=800
colorspace1="RGB"
filt="LanczosRadius"
filtering="-filter $filt"
gammaval=3
igammaval=`convert xc: -format "%[fx:1/$gammaval]" info:`
inname=`convert $infile -format "%t" info:`

# resize in RGB with and without gamma and blend by (intensity of non-gamma resized image)
# line1: read input, convert to 16bits and desired colorspace (RGB)
# line2: clone the first image and use LanczosRadius to scale by 800 (in RGB)
# line3: clone the first image, apply gamma, use LanczosRadius to scale by 800 and apply inverse gamma
# line4: clone the resized RGB (no gamma applied) image and convert to gray (intensity) and use -auto-level to stretch to full dynamic range
# line5: composite (-compose over) the images from lines 2,3,4 (in RGB) using the last image as a mask to do the blending
# line6: delete the temps
# line7: convert back to sRGB and save output
convert $ $infile -depth 16 -set colorspace sRGB -colorspace $colorspace1 $ \
$ -clone 0 $filtering -distort Resize $scale% -write tmp1.png $ \
$ -clone 0 -gamma $gammaval $filtering -distort Resize $scale% -gamma $igammaval -write tmp2.png $ \
$ -clone 1 -colorspace gray -auto-level $ \
$ -clone 2 -clone 1 -clone 3 -compose over -composite -write tmp3.png $ \
-delete 0-3 \
-set colorspace $colorspace1 -colorspace sRGB ${inname}_${filt}_blended_s${scale}_g${gammaval}_$colorspace1.png

The -write commands are unnecessary. Quoting Fred: "I also save 3 tmp.png files to show the non-gamma applied resize in RGB, the gamma applied resize in RGB and blended resize in RGB just to be sure the blending was working."
P.S. As pointed out by Bart van der Wolf below, there was a typo, which is now fixed in the now correct code above.

NicolasRobidoux · « **Reply #7 on:** July 18, 2014, 04:22:10 am »

Another brainstorm: Fix the pair of gammas so that near the relevant midtones (which are generally quite low in linear RGB) the blended combination of them resembles linear RGB.

Bart_van_der_Wolf · « **Reply #8 on:** July 18, 2014, 04:46:48 am »

Quote from: NicolasRobidoux on July 18, 2014, 03:56:45 am

Bart:

I have high hopes that something good can be squeezed of this research direction.

Nicolas: Same hopes that I have. Thanks for sparking that idea, the results already look promising. A down sample of a star target or a zoneplate/rings target look very nice, which is important for photographers who produce web publishing content. Low aliasing and ringing/haloing is paramount for such operations.

Linear Light mixing of colors with downsampling avoids color issues that can arise with gamma pre-compensated downsampling. So that is also something to keep in mind.

Quote

1) The reason for using "a pair of opposite gamma spaces" is to restore some black/white symmetry. I think that, however, the alpha should then be computed from either some sort of average of the two results or from linear light, in which case there would be three resampled images used to recombine: through RGB gamma 3 (for example), through RGB gamma 1/3, and linear RGB (gamma 1). These thoughts are a bit rough. Maybe one should work in a pair of direct/reverse video after normalizing the input image, then de-normalizing? Assuming the normalization anchors things at the black and white points (roughly), this would definitely restore black/white symmetry. (Quickly brainstorming, here.)

Chaos rules the universe, so a bit of brain storm cannot hurt

Quote

Poking really quickly into the first idea above, however, one would need a very accurate floating point toolchain to pull off an initial -gamma .3333333333333. Not sure, so this is more a "watch for this" than a true "jump up and down warning". But I'm a bit concerned that Q16 is not enough.

Definitely something to keep in mind, especially since only 16-b/ch pre-compiled binaries are available for download and installation by mere mortals. Having said that, we can 'blend away' the erroneous ranges by a good choice of thresholds or shape of the Alpha channel response curve(s). Lot's of testing ahead.

Quote

Mixing linear with gamma 3 sounds like a reasonable practical approach. But it definitely does not respect black/white symmetry.

Agreed.

Quote

2) EWA LanczosRadius is not interpolatory. Unless you explicitly used a hard wired "null" operation, there will be a difference when do "no-op" resampling. In practice, this difference could be argued to be a good thing (with EWA LanczosSharpest 4, for example). The real question is whether the final answer differs significantly from an infinite precision version of the result. I'm just making sure here, that you know (the reasonable assumption, namely that you do know, can be dangerous) that there are two sources for deviation from the original when resizing to the exact same dimensions: round off error and the fact that the filter actually does some filtering in all cases.

Yes, that's why it was only a quick test on a single image to see if there are huge issues with the current implementation. Things are not totally screwed up, they on the contrary produce only small changes in suspect regions with the current implementation.

Quote

3) Fred Weinhaus has started optimizing the code further and poking around. We'll post things in the IM forums as soon as I've had time to check things over and organize results (and my thoughts) into something halfway intelligible.

Great, Fred knows IM scripting like few others do, although he uses a specific scripting dialect. Anyway, the image results should be identical if the scripting can be ported to other dialects.

Cheers,
Bart

NicolasRobidoux · « **Reply #9 on:** July 18, 2014, 04:51:51 am »

For now, http://www.imagemagick.org/discourse-server/viewtopic.php?f=22&t=25935 will be the centralized point for discussion of this new approach within the ImageMagick Forums.
I'll jump back and forth between there and here.

NicolasRobidoux · « **Reply #10 on:** July 18, 2014, 05:19:02 am »

With very preliminary results courtesy of Fred Weinhaus (on the "wizard" image, which is a drawing, not a photograph), enlarging through gamma 3 looks better than enlarging through L*a*b*; I suspect that this has to do with the "non-smooth" correspondence between linear light and L*a*b*).

NicolasRobidoux · « **Reply #11 on:** July 18, 2014, 05:56:42 am »

Quote from: BartvanderWolf on July 18, 2014, 03:57:17 am

...
Correct. The current alpha channel calculation uses the Gray colorspace (Gray = 0.298839*R+0.586811*G+0.114350*B) conversion. But that is just one of many possible alpha channel creations. One could even add a Sigmoidal S-curve to the alpha channel, should that provide better blending between the other layers (one with 'shadow halos' and the other with 'highlight halos)'. It's flexible enough to optimize any way one desires.
...

IMHO it's really important that the alpha channel be "stable" (this roughly means "boring", with as few kinks and slope discontinuities and whatever) w.r.t. image data so that the blending not add aliasing. A straight line in linear light between the min and max image values (possibly filtered to reject outliers, although noise reduction should have been performed before resampling) fits the bill. It may be possible to do better, but this is a case of "proceed with caution".

NicolasRobidoux · « **Reply #12 on:** July 18, 2014, 12:57:23 pm »

Again courtesy of Fred Weinhaus, the Windows version of the basic command:

convert ( image.png -depth 16 -set colorspace sRGB -colorspace RGB ) ^
( -clone 0 -filter LanczosRadius -distort Resize 800% ) ^
( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.33333333 ) ^
( -clone 1 -colorspace gray -auto-level ) ^
( -clone 2 -clone 1 -clone 3 -compose over -composite ) ^
-delete 0-3 ^
-set colorspace RGB -colorspace sRGB ^
result.png

P.S. As pointed out below by Bart van der Wolf, there was a typo in the code above, which is now fixed.

Bart_van_der_Wolf · « **Reply #13 on:** July 18, 2014, 03:42:08 pm »

Quote from: NicolasRobidoux on July 18, 2014, 12:57:23 pm

Again courtesy of Fred Weinhaus, the Windows version of the basic command:
convert ( image.png -depth 16 -set colorspace sRGB -colorspace RGB ) ^
( -clone 0 -filter LanczosRadius -distort Resize 800% ) ^
( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800% -gamma 0.33333333 ) ^
( -clone 1 -colorspace gray -auto-level ) ^
( -clone 1 -clone 2 -clone 3 -compose over -composite ) ^
-delete 0-3 ^
-set colorspace RGB -colorspace sRGB ^
result.png

Hi Nicolas,

Sweet, nice and compact, and totally in memory, no temporary files on disk. My compliments to Fred.

Just one remark, an error IMHO:

( -clone 1 -clone 2 -clone 3 -compose over -composite ) ^

should be

( -clone 2 -clone 1 -clone 3 -compose over -composite ) ^

Clone 1 and Clone 2 should be reversed to remove the shadow-edge undershoot.

Also, '%' signs must be preceded by another percentage sign like this %%, if used in a batch script file instead of on the commandline. So 800% becomes 800%% as Resize percentage in a batch file.

With a small alteration, a batch file also becomes more flexible in drag-and-drop behavior (it accepts any filename dragged on the batch file, and drops a resampled PNG version in the same directory as the original):

convert ( "%~dpnx1" -depth 16 -set colorspace sRGB -colorspace RGB ) ^
( -clone 0 -filter LanczosRadius -distort Resize 800%% ) ^
( -clone 0 -gamma 3 -filter LanczosRadius -distort Resize 800%% -gamma 0.33333333 ) ^
( -clone 1 -colorspace gray -auto-level ) ^
( -clone 2 -clone 1 -clone 3 -compose over -composite ) ^
-delete 0-3 ^
-set colorspace RGB -colorspace sRGB ^
"%~dpn1_800%%.png"

I'd also have to take another look at the '-auto-level' option to see if it is the best choice for non-synthetic images, rather than a '-contrast-stretch 0x0' or similar.

I'm also still looking for a better solution to retain the original file's color profile (important in a color managed environment), e.g. Adobe RGB or ProPhoto RGB, and assign it again to the output file. If Fred has any suggestions, I'd be a happy camper.

Cheers,
Bart

NicolasRobidoux · « **Reply #14 on:** July 18, 2014, 05:05:49 pm »

Quote from: BartvanderWolf on July 18, 2014, 03:42:08 pm

...
Clone 1 and Clone 2 should be reversed to remove the shadow-edge undershoot.
...

Indeed.

Bart_van_der_Wolf · « **Reply #15 on:** July 18, 2014, 07:13:52 pm »

As a result of the code optimization suggested by Fred Weinhaus, and a few tweaks of my own doing, I've updated the Windows batch script file that I posted earlier. I've attached it as a Zip archive.

An important change to the size input was made!

Now one does need to enter a percentage sign (%) after the value if one wants to do a resizing based on percentage. So a 50% entry will reduce the size of the image to half of the original size. The reason I changed it was to add more flexibility in getting an exact output size, instead of a percentage with lots of decimals to avoid 1 pixel round-off errors.

Now, one can alternatively enter the required size of the output in pixels, e.g. 800x800. This will fit the largest original image dimension to 800 pixels in output, regardless whether it's in a landscape or portrait orientation, and scale the shorter dimension proportionally.

I've also made some preparations that will save the resampled image in the highest possible JPEG or PNG quality, by preventing chroma sub-sampling, and setting the compression quality to the maximum, i.e. 100. This is in preparation to a fix (if possible) that will maintain the original file's embedded ICC color profile and embed it in the resampled version as well. For the time being, the output will be a PNG filetype without embedded profile.

Enjoy.

Cheers,
Bart

Bart_van_der_Wolf · « **Reply #16 on:** July 19, 2014, 07:31:07 am »

Quote from: BartvanderWolf on July 18, 2014, 07:13:52 pm

I've also made some preparations that will save the resampled image in the highest possible JPEG or PNG quality, by preventing chroma sub-sampling, and setting the compression quality to the maximum, i.e. 100. This is in preparation to a fix (if possible) that will maintain the original file's embedded ICC color profile and embed it in the resampled version as well. For the time being, the output will be a PNG filetype without embedded profile.

*** UPDATE ***

I've found a solution for the embedding of the color profile, it seems ...

-convert "input.tif" -write "IMsource.icc" apparently saves a copy of the embedded color profile, and
-profile ÏMsource.icc" will assign that profile to the file that will be written. I'm still searching for a way to do it without having to write a temporary file ...

The script (or rather ImageMagick) will produce warning messages if no profiles are embedded, but the conversion is still performed as intended, just without profile.

Attached is an updated version (version 1.0.3). The tool now copies the original profile that is embedded in the original image, and embeds that in the resized version. It also retains the original file type, so a JPEG remains a JPEG, and a TIF remains a TIF, it just has a different size, as indicated by the new file name, but now with the same profile as the original source.

Cheers,
Bart

NicolasRobidoux · « **Reply #17 on:** July 19, 2014, 08:36:27 am »

Fred Weinhaus http://www.fmwconcepts.com/fmw/fmw.html has asked me what's wrong with sigmoidization, which does suppress both dark and light halos and has been found to work fairly well. Wrong to the extent that I declare it "dead" as a general purpose resampling method.
(Sigmoidization is an ancestor of the methods discussed here and is described here: http://www.imagemagick.org/Usage/resize/#resize_sigmoidal.)
Basically, what is wrong with it is that it leads to "color separation", and this failing means that if sigmoidization is strong, one has to visually inspect the images to make sure taming the halos did not lead to other artifacts.
This is (apparently) not the case with the new methods discussed here: Resampling through a pair of gamma spaces, and blending with an alpha which is the same over all three channels (a normalized luminance or luma), means that the resulting method satisfies http://www.luminous-landscape.com/forum/index.php?topic=77949.msg745796#msg745796. I believe that, provided one works in a colorspace in which channels are monotone w.r.t. a reasonable luminance (RGB or XYZ, for example), this is a very very important property.
-----
There is something else that I believe >>may<< be wrong with sigmoidization: As much as possible, the intermediate color space(s) should >>locally<< be linear, and if nonlinear it should be nonlinear in a very smooth way. The sigmoidal color spaces have "kinks". I believe that in some situations this adds aliasing and color artifacts. "Gamma spaces" are very smooth, and consequently they "locally" (in the sense of near a given color value) are "almost linear". The same could be said of sigmoidal color spaces, but for the same amount of (one of the types of) halo suppression, the extent over which the tangent to a sigmoidal curve approximates it is smaller, overall, than a similarly strong gamma space.
-----
(My apologies if this is not particularly well explained. I edited this poor explanation a bit after Fred Weinhaus made it clear that some of it was more confusing than informative.)

NicolasRobidoux · « **Reply #18 on:** July 19, 2014, 11:32:24 am »

Suggested variant:
Instead of blending the gamma resample with linear light, negate the linear light version of the input image, use the same gamma, resample the same way, undo the gamma, negate again (to be back in linear light).
Then, use the luminance of the average of the two results instead of the linear light resample's luminance (which is not computed anymore), normalized of course, as alpha (blending parameter).
Why? The core of the method is then black/white symmetric.
-----
I am far from certain that this, or something like it, would give better results than the "blend linear light with gamma" version. The HVS (like "the real world) is >>not<< black/white symmetric.
The other difficulty is that for this to work well we most likely need to set the "white" used by the negation operators to fit the input and resampled images well.

Jack Hogan · « **Reply #19 on:** July 19, 2014, 02:01:03 pm »

Great work guys, this is very useful. A couple of questions:

1) Is the script optimized for enlarging as opposed to shrinking? I am asking because I see gammas greater than one flying around :-)
2) If one works in AdobeRGB, is it enough to simply change all references of 'sRGB' to 'AdobeRGB' in the script?
3) I sometimes generate a B&W image directly from a Bayer raw file. The resulting full resolution 'grayscale' TIF is still linear (gamma=1). Assuming one wanted to downsize only, could all the colorspace changing, gamma and cloning be replaced by a single line such as
convert "%~dpnx1" -filter LanczosRadius -distort Resize %Msize% ?
4) If one wanted a TIFF as an output would they simply leave out the -quality line?

Thank you very much!
Jack

Author Topic: A free high quality resampling tool for ImageMagick users (Read 252444 times)