Batch Convert: JPG to 8bit - stays multicoloured

[Peter2]

I have JPGs with 200.000 colors and want to convert them to "8 bit - 8 colours". When I do it in the standard command file by file, I get 8 colours.

Then I tried it with Batch Convert - and get still 40-50.000 colors. I stored the settings in a XBS:

Code: Select all

  <?xml version="1.0" encoding="UTF-8" ?> 
- <XnView_script version="1.0" name="JPG_to_8Colors">
  <Change_color_depth method="1" dither="5" ncompo="8" alpha="255" replace_alpha="false" back_color="#ffffff" /> 
- <Output folder="" filename="{Filename}_8Farb" case="0" startIndex="1" format="JPEG">
  <Options overwrite="1" orgDate="true" keepMeta="true" keepICC="false" keepFolder="true" checkFilesize="false" keepParentFolder="true" keepExtension="true" delOrg="false" multipage="false" allPages="false" openExplorer="false" beep="true" openBrowser="false" clearItems="false" /> 
  <JPEG quality="80" progressive="false" optimizeHuffman="true" rebuildThumb="true" orgQuality="true" DCTMethod="0" subSampling="0" smoothFactor="0" /> 
  </Output>
  </XnView_script>

What's going wrong?


Edit:
And when I want to make "16 grey", I get "256 grey":

Code: Select all

  <?xml version="1.0" encoding="UTF-8" ?> 
- <XnView_script version="1.0" name="JPG_to_16Grey">
  <Change_color_depth method="2" dither="1" ncompo="16" alpha="255" replace_alpha="false" back_color="#ffffff" /> 
- <Output folder="" filename="{Filename}_16Grau" case="0" startIndex="1" format="JPEG">
  <Options overwrite="0" orgDate="true" keepMeta="true" keepICC="false" keepFolder="true" checkFilesize="false" keepParentFolder="true" keepExtension="true" delOrg="false" multipage="false" allPages="false" openExplorer="false" beep="true" openBrowser="false" clearItems="false" /> 
  <JPEG quality="80" progressive="false" optimizeHuffman="true" rebuildThumb="true" orgQuality="true" DCTMethod="0" subSampling="0" smoothFactor="0" /> 
  </Output>
  </XnView_script>

[user0]

When I do it in the standard command file by file, I get 8 colours.

are you sure? jpg is lossy format
reopen saved file and count colors

[cday]

When I do it in the standard command file by file, I get 8 colours.

are you sure? jpg is lossy format
reopen saved file and count colors

... but an image consisting of (for example) 8 colours when saved as a JPEG will still contain 8 colours when opened, although other details will in general suffer loss. Just tested, to confirm that to be the case.

I have in the past reduced the number of colours in scans of old documents to produce more pleasing images with less background colour variation.

[XnTriq]

JPEG only supports 8-bit grayscale (256 shades of gray) and truecolor (167'77'216 colors).
Even if you save a binary image consisting of just pure black (#000000) and pure white (#ffffff) as grayscale JPEG, gray artifacts will be introduced during compression – regardless of the settings you choose.
These artifacts aren't always noticeable to the naked eye, but XnView's Image → Map → Equalize command will bring them to light.

p201581_1.png

p201581_2.png

Related:

• Converting Grayscale file to JPEG
• Information: Convert to 256 color space not possible with JPG

[cday]

JPEG only supports 8-bit grayscale (256 shades of gray) and truecolor (167'77'216 colors).

But that doesn't mean that the number of colours in an image saved as a JPEG may change, images containing eight colours such as Peter2's images still contain only eight colours when saved to JPEG format.

In my test 8-colour image XnView MP still displays the number of colours after saving as a JPEG as eight; Peter2's issue in the first post in the thread concerned the number of colours contained in his converted images rather than how they displayed, suggesting that the conversion was not being performed correctly.

[user0]

check how quantization works in jpeg, even at 100% quality(+best dct,subsampling) your original 2-8-whatever colors will not remain intact at the edges and every artifact is a new color.

In my test 8-colour image XnView MP still displays the number of colours after saving as a JPEG as eight

that's app "drawback", you either have to reload JPG after save via Ctrl+R or reopen file to see the real number of colors.

[cday]

check how quantization works in jpeg, even at 100% quality(+best dct,subsampling) your original 2-8-whatever colors will not remain intact at the edges and every artifact is a new color.

I think the issue is that when a JPEG is decoded for display artifacts not present in the JPEG file are introduced?

In my test 8-colour image XnView MP still displays the number of colours after saving as a JPEG as eight

that's app "drawback", you either have to reload JPG after save via Ctrl+R or reopen file to see the real number of colors.

That's what I did, and the displayed number of colours remained at eight, no doubt an image of the screen might have shown additional colours introduced when the image was decoded. Easy to test and confirm...

Anyway, let's not lose sight of Peter2's possible bug report...

[XnTriq]

In my test 8-colour image XnView MP still displays the number of colours after saving as a JPEG as eight;

Could you please provide a sample image?

[cday]

Could you please provide a sample image?

OK, apologies, my methodological error was counting the colours in the converted image still open on the screen, although when I posted yesterday evening and again this morning I thought that I had reopened the saved file. Point taken.

But reading Peter2's post at the start of the thread, I don't think that what he is reporting relates to this issue, maybe he can clarify...

[XnTriq]

I created a PNG image with 8 unique colors.

8_colors.png

██ 0/0/0
██ 0/0/255
██ 0/255/0
██ 0/255/255
██ 255/0/0
██ 255/0/255
██ 255/255/0
██ 255/255/255

If this PNG is converted to JPEG with XnView's (libjpeg) highest quality settings, the number of colors stays the same, and there's only a slight shift in some color values:

██ 0/0/0
██ 0/0/254 ←
██ 0/255/1 ←
██ 0/255/255
██ 254/0/0
██ 255/0/254 ←
██ 255/255/0
██ 255/255/255

If the quality settings are lowered, more colors are added as a result.

[cday]

Thanks, that is interesting as I had an image of a scanned page that I had previously reduced to eight colours and saved as a JPEG which was shown as containing only eight colours, and the file size was consistent with its having been saved at a high Q value.

Unfortunately I can't immediately find it now, or the scan from which it was created. Something else learned, but not very practical when archiving quantities of images! However, reducing the number of colours in the scan of an old document as an enhancement method to improve its appearance when viewed, through reducing the variation in the page colour, would probably survive useful compression.