IM convert leads to loss of details on a 16-bit tif image

[swiss_knight]

Hi.
I have a 16-bit depth tif image with 4 channels (each channel is 16-bit).
"identify" says it's a sRGB image. No problem till here.

Theses channels are "automatically" detected by image software like Photoshop as RGBA, in this precise order. It's natural to all conventional images.
But in fact my image isn't conventional ; its channels are : infrared(IR),R,G,B. In this order. It was acquired by a special camera.
So the image looks red on theses software because all channels are shifted : IR becomes red (it's the brighter channel), red becomes green, green -> blue, and blue -> A (so is lost as a color).

The basic idea is to use IM to extract the channels 2,3 and 4 which correspond respectively to R,G and B (the channel 1 is the IR channel).
And recombine these 3 only in a new RGB image to have a "normal" image corresponding to the reality, as perceived by our eyes.
(or much better, a RGB"IR" as a RGBA. Thus "cheating" the softwares by placing the IR channel at the last position instead of the first one).

I'm using this for the moment :
(following these indications : http://www.imagemagick.org/script/comma ... hp#channel )

Code: Select all

convert image.tif -channel ARGB -separate channels_%d.tif

After what, I do :
(channels_0.tif is infrared)

Code: Select all

convert channels_1.tif channels_2.tif channels_3.tif -channel RGB -combine image_recombined.tif 

It works. But...

First, the original image weights X Mo.
All 4 separated channels images weight a lot less than X/4 Mo each. it's really strange !
And of course, the recombined image, weights a lot less (~half) than the original image.
This is unfortunately visible ; I feel I'm having a highly compressed JPG image on my eyes. Theres is some "flat color zones" and a high loss of details. I precise I'm working with *.tif images only. I do not applied any other commands as the ones shown here.
Am I doing something wrong ?

Any help appreciated, thanks a lot !
( I'm using this version of IM on Windows 7: ImageMagick-7.0.3-0-portable-Q16-x86.zip from here: ftp://ftp.imagemagick.org/pub/ImageMagick/binaries/ )

[GeeMack]

Am I doing something wrong ?

You might try putting "-compress none" and "-depth 16" just before the output filename in both of your commands.

[fmw42]

Your tiff may be uncompressed and afterwards gets compressed. TIF supports several compressions, LZW, ZIP and JPG. Default may be LZW.

You do not need to save temporaries. You can do it all in one step.

Code: Select all

magick image.tif -channel rgba -separate ^
( -clone 1-3 -set colorspace sRGB -combine -colorspace RGB ) ^
-delete 1-3 +swap ^
-alpha off -compose copy_opacity -composite ^
-depth 16 -compress none newimage.tif

[snibgo]

First, the original image weights X Mo.
All 4 separated channels images weight a lot less than X/4 Mo each.

I don't understand. Perhaps you can upload an example input to somewhere like dropbox.com and paste the URL here.

[swiss_knight]

Hi.

The first (GeeMack) of the two previous solution doesn't work. I ended with the exact same result as before.
The second (fmw42) leads to an almost transparent image (who weights 1.0 Mo). So it doesn't work either.

Here is what it should look like :
http://pix.toile-libre.org/upload/origi ... 884822.png
Here is the image after channels extraction and recombination :
http://pix.toile-libre.org/upload/origi ... 884946.png

(these are pngs, I can't upload directly the tif)

We can clearly see the loss of quality, it looks like a JPG compression. Even if the '-compress' option was set to 'none'.

The original image weights 2.1 Mo.
The 4 separated channels weight 260 Ko each. So 4x260=1040Ko != 2.1Mo.
And the recombined image is 781 Ko. Which is neither 2.1 Mo.

I've added both '-compress none' and '-depth 16' to the first command.

Thanks a lot.

[snibgo]

Oh, "weight" is the number of bytes in the file?

1473884946.png is smaller because it compresses better, because it contains only 136 different colours, according to "identify -verbose".

Please link to the tiff that was the input for 1473884946.png. If you can't do that, then "identify -verbose 1473884946.png >4946.txt and post the text file here.

And show the exact command that converted the input tiff to 1473884946.png.

[fmw42]

You asked to move the IR channel from first to last and make it the alpha channel (infrared(IR),R,G,B. ). My command above does just that. So you IR channel must be very dark if the image is mostly transparent. Perhaps you need to -auto-level or -negate the IR channel before making it the alpha channel.

Line1: separate all 4 channels (0,1,2,3) assuming that the last channel is the alpha channel
Line2: copy the 1-3 channels and recombine as RGB image
Line3: delete the original RGB (1-3) channels and swap the original channel 0 (IR) with the new RGB image
Line4: turn alpha off, then put the IR channel into the alpha channel of the new RGB mage
Line5: set to depth 16, set compression to none and save the output

Code: Select all

magick image.tif -channel rgba -separate ^
( -clone 1-3 -set colorspace sRGB -combine -colorspace RGB ) ^
-delete 1-3 +swap ^
-alpha off -compose copy_opacity -composite ^
-depth 16 -compress none newimage.tif

If you want a smaller filesize in Bytes, then use -compress LZW, ZIP or JPG depending upon whether you want lossless or lossy compression.

If the IR channel is too dark, then do something like

Code: Select all

magick image.tif -channel rgba -separate ^
( -clone 1-3 -set colorspace sRGB -combine -colorspace RGB ) ^
-delete 1-3 +swap ^
( +clone -auto-level ) ^
+swap +delete ^
-alpha off -compose copy_opacity -composite ^
-depth 16 -compress none newimage.tif

That clones the IR channel and stretches the graylevels to full dynamic range. Then it swaps it with the unchanged IR channel and deletes the last image which is the original unchange IR channel. The rest is the same as earlier.

P.S. I would be surprised if IM can properly read a 4 channel TIFF image, if the 4th channel is not a proper alpha channel. Unless, you treat it as CMYK

If you keep the 4 channels as separate images, then IM can properly put them in any order you want and any one can be put into the alpha channel. Or keep the RGB channels as one tiff image and IR channel as a separate grayscale image. Then IM can combine them as above using -compose copy_opacity.

If you want to provide a link to your input 4 channel Tiff, we can take a look and make sure the 4 channel is a proper alpha channel.

[swiss_knight]

Hi,

Focus only on the quality loss as it's my main concern now.

In fact, even a simple IM command leads to a loss of quality on my 16bit tif images.
Here is a sample: http://pix.toile-libre.org/upload/origi ... 059547.png
You must change the extension to .tif instead of .png after download (limitation of this website based on file extension, it didn't accept .tif files).
(Download it with wget or right click > save target as, as it won't appear in your browser normally.)


Information is coded on 16bits in this file but there is truly 12bits where there is some information, the 4 last bits are "lost" (the software creating these images handles only 8bit per 8bits for saving data). So, only a software capable of reading 16-bits and not only 8 will be able to open the image without "compression" artifact. Like Photoshop e.g. It's also why it looks really dark.

So, when doing a -convert *simple stuff* to output.tif on the original image, then, even in Photoshop, there is a lot less colors displayed.

Thanks a lot for your help.


Here's the identify -verbose result on this file (run from my personnal linux machine) (I have shorten the histogram values) :

Code: Select all

Image: myimage.tif
  Format: TIFF (Tagged Image File Format)
  Mime type: image/tiff
  Class: DirectClass
  Geometry: 693x6825+0+0
  Resolution: 1x1
  Print size: 693x6825
  Units: Undefined
  Type: Grayscale
  Endianess: LSB
  Colorspace: Gray
  Depth: 16/8-bit
  Channel depth:
    gray: 8-bit
  Channel statistics:
    Pixels: 4729725
    Gray:
      min: 0 (0)
      max: 65535 (1)
      mean: 5330.97 (0.0813454)
      standard deviation: 13492.3 (0.20588)
      kurtosis: 8.65182
      skewness: 3.12217
  Colors: 256
  Histogram:
      2784: (    0,    0,    0) #000000000000 gray(0)
    936159: (  257,  257,  257) #010101010101 gray(1)
   1390581: (  514,  514,  514) #020202020202 gray(2)
    (...)
      3821: (65278,65278,65278) #FEFEFEFEFEFE gray(254)
      3008: (65535,65535,65535) #FFFFFFFFFFFF gray(255)
  Rendering intent: Undefined
  Gamma: 0.454545
  Background color: gray(255)
  Border color: gray(223)
  Matte color: gray(189)
  Transparent color: gray(0)
  Interlace: None
  Intensity: Undefined
  Compose: Over
  Page geometry: 693x6825+0+0
  Dispose: Undefined
  Iterations: 0
  Compression: None
  Orientation: TopLeft
  Properties:
    date:create: 2016-11-29T21:18:38+01:00
    date:modify: 2016-11-29T08:57:36+01:00
    signature: dc027957e137f31b207367bd2845457ff560310f0e0c1dd4d1357ecffb652b92
    tiff:alpha: unspecified
    tiff:endian: lsb
    tiff:photometric: min-is-black
  Artifacts:
    filename: myimage.tif
    verbose: true
  Tainted: False
  Filesize: 10.62MB
  Number pixels: 4.73M
  Pixels per second: 236.5MB
  User time: 0.010u
  Elapsed time: 0:01.019
  Version: ImageMagick 6.8.9-9 Q16 x86_64 2016-11-29 http://www.imagemagick.org

And the exiftool -all -G0 command result:

Code: Select all

[ExifTool]      ExifTool Version Number         : 10.10
[File]          File Name                       : myimage.tif
[File]          Directory                       : .
[File]          File Size                       : 10 MB
[File]          File Modification Date/Time     : 2016:11:29 08:57:36+01:00
[File]          File Access Date/Time           : 2016:12:06 22:23:07+01:00
[File]          File Inode Change Date/Time     : 2016:11:29 21:18:38+01:00
[File]          File Permissions                : rw-rw-r--
[File]          File Type                       : TIFF
[File]          File Type Extension             : tif
[File]          MIME Type                       : image/tiff
[File]          Exif Byte Order                 : Little-endian (Intel, II)
[EXIF]          Subfile Type                    : Full-resolution Image
[EXIF]          Image Width                     : 693
[EXIF]          Image Height                    : 6825
[EXIF]          Bits Per Sample                 : 16
[EXIF]          Compression                     : Uncompressed
[EXIF]          Photometric Interpretation      : BlackIsZero
[EXIF]          Samples Per Pixel               : 1
[EXIF]          Min Sample Value                : 0
[EXIF]          Max Sample Value                : 65535
[EXIF]          X Resolution                    : 1
[EXIF]          Y Resolution                    : 1
[EXIF]          X Position                      : 0
[EXIF]          Y Position                      : 0
[EXIF]          Resolution Unit                 : None
[EXIF]          Tile Width                      : 256
[EXIF]          Tile Length                     : 256
[EXIF]          Tile Offsets                    : (Binary data 640 bytes, use -b option to extract)
[EXIF]          Tile Byte Counts                : (Binary data 566 bytes, use -b option to extract)
[Composite]     Image Size                      : 693x6825
[Composite]     Megapixels                      : 4.7

[fmw42]

I think you will likely need to provide and example input for us to test.

[snibgo]

Downloading and renaming that file to be 1481059547.tiff, then using "identify -verbose", shows the file is 16 bit grayscale but with only 8 bits of data. They have been extended by replication in the usual way to make 16 bits.

What is the problem? Do you want something different? Did you make this file from some other file? If so, then what was that file, and what command did you use to make it?

[swiss_knight]

Hi,

here is a print screen of a zoom on a Photoshop window while the original image (the one the link targets in my previous post) was loaded:



And here is a print screen of a zoom of the image resulting after some processing with -convert (e.g. a cropping, for example), again taken within the Photoshop window to the same pixel size level :




When I crop the original image with an other tool (e.g. gdal_translate, or the scissors in Photoshop), the resulting image is exactly the same as the original one.
When I process the image with IM tools, it's not.
I wonder why. And how to fix this, if it's possible.

Thanks again.

(Note: these are only jpeg captures of Photoshop window, not the original images files !)

[snibgo]

So, you process an image with IM, and the output looks different to the original? Is that what you are saying?

What IM command did you use? You have linked an output (1481059547.tiff) but not the input.

[swiss_knight]

Yes, it's what I meant: IM processing leads to "some kind" of quality loss with this 16-bit tif image file as input.

The file I uploaded was the input.
I'll double check that tomorrow but it's normally the input, not the output, so, whatever command, like a -convert crop (or, initially a -convert combine with 2 other images as other bands) should lead to the second image.
It's the result I always had. It look like some compression, like one can see on JPEG images for example.
At least when the resulting file is opened within Photoshop, as it's the only software I can use to really read a 16-bit tif image.

[snibgo]

I don't understand what problem you have. The file you link to, 1481059547.tiff, is grayscale, with only 256 levels of gray. The format is 16-bit, but only 256 values are used.

The image is very dark, virtually black. "-auto-level -auto-gamma" helps us to see it, but there are still only 256 different values.

If this file is the input, then:
- What IM command are you using to process it?
- What is wrong with the output?

[swiss_knight]

hmmm.... That's strange.

I'll check that later on, but when I stretch the histogram to better see the original input image with Photoshop, it looks like the first previously shown jpg print screen.
Then, when I use imagemagick (whatever command), the output looks like the second jpg print screen.


The original image doesn't come from an IM command, it comes from a proprietary scanning software.