Converting Grayscale file to JPEG

[cday]

When the attached 8-bit grayscale file is used as input for the following code:

Code: Select all

nconvert -out jpeg -q 80 Test.tif

...the error message below is displayed:

Code: Select all

Error: This picture cannot be written using this format (Test.jpg)

The file can be saved as a JPEG using XnView MP...

Does the above code need to be modified, or is there a bug in NConvert?

Note: Similar result with grayscale PNG, and NConvert versions 7.20 and 6.35.

Test.zip

[xnview]

this picture has a greyed colormap, so you need to force with -grey

[cday]

this picture has a greyed colormap, so you need to force with -grey

Thanks, the Help files gives the option as:

Code: Select all

-grey num         : Convert in Grey Scale (256, 128, 64, 32, 16, 8 or 4)

Inserting -grey 64 into the above code:

Code: Select all

nconvert -grey 64 -out jpeg -q 80 Test.tif

...produces the expected JPEG, but the created file seems to have 256 'colours' whatever num value is used... [Unexplained.]

[XnTriq]

...produces the expected JPEG, but the created file seems to have 256 'colours' whatever num value is used... [Unexplained.]

I believe that's because the JPEG/JFIF file format doen't support these bit depths:

• 2-bit grayscale → 4 levels of gray
• 3-bit grayscale → 8 levels of gray
• 4-bit grayscale → 16 levels of gray
• 5-bit grayscale → 32 levels of gray
• 6-bit grayscale → 64 levels of gray
• 7-bit grayscale → 128 levels of gray

PNG grayscale images support the widest range of pixel depths of any image type. Depths of 1, 2, 4, 8, and 16 bits are supported, covering everything from simple black-and-white scans to full-depth medical and raw astronomical images.

[….]

The most common form of JPEG (the one that uses “lossy” compression, in which some information in the image is thrown away) likewise supports grayscale images in depths of 8 and 12 bits. In addition, there are two variants that use truly lossless compression and support any depth from 2 to 16 bits: the traditional version, known simply as “lossless JPEG”, and an upcoming second-generation flavor called “JPEG-LS”. But the first is extremely rare, and is supported by almost no one, despite having been standardized years ago, and the second is also currently unsupported (although that is to be expected for a new format). Lossy JPEG is very well supported, thanks largely to the Independent JPEG Group's free libjpeg (which, like libtiff, has become the de facto standard for JPEG encoding and decoding) – but, of course, it's lossy. Note that libjpeg can be compiled to support either 8-bit or 12-bit JPEG, but not both at the same time. Thus, from a practical standpoint, only 8-bit, lossy grayscale is supported.

[cday]

...produces the expected JPEG, but the created file seems to have 256 'colours' whatever num value is used... [Unexplained.]

I believe that's because the JPEG/JFIF file format doen't support these bit depths:

• 2-bit grayscale ~ 4 levels of gray
• 3-bit grayscale ~ 8 levels of gray
• 4-bit grayscale ~ 16 levels of gray
• 5-bit grayscale ~ 32 levels of gray
• 6-bit grayscale ~ 64 levels of gray
• 7-bit grayscale ~ 128 levels of gray

Good point, JPEG does indeed only support 8-bit depth grayscale (256 levels)...

But using the -grey forcing switch without a num value didn't work, but perhaps surprisingly any of the small number of num values I tried did produce the required result. Of course, those values could produce a valid PNG, for example, as you indicate.

[XnTriq]

Good point, JPEG does indeed only support 8-bit depth grayscale (256 levels)...

But using the -grey forcing switch without a num value didn't work, but perhaps surprisingly any of the small number of num values I tried did produce the required result. Of course, those values could produce a valid PNG, for example, as you indicate.

So, should the -grey parameter (w/o num switch) produce 8-bit grayscale images (regardless of the output format) by default?

[cday]

Good point, JPEG does indeed only support 8-bit depth grayscale (256 levels)...

But using the -grey forcing switch without a num value didn't work, but perhaps surprisingly any of the small number of num values I tried did produce the required result. Of course, those values could produce a valid PNG, for example, as you indicate.

So, should the -grey parameter (w/o num switch) produce 8-bit grayscale images (regardless of the output format) by default?

Or possibly values other than 256 produce an error message?

Pierre?