| Author |
 Topic  |
|
|
shackers
United Kingdom
28 Posts |
 Posted - Jan 01 2021 : 08:37:08
|
I have a text document printed from word, which has thick orange and yellow borders and dark grey text. There are effectively only 4 colours in the original document: orange, yellow, dark grey and white.
I have scanned this document at a fairly high resolution and saved it to file PNG format (size 24MB). Using ImageEnProc to calculate the number of colours the result is 200278.
I have saved the PNG file to GIF format using MS Paint. The resulting file size is 4.85MB.
There doesn't appear to be a huge difference between the two files when looked at on the screen. When zooming in I can see that there is a lot more "smoothing" on the PNG than the GIF.
Is this very large discrepancy between the colour calculation for these two different formats to be expected?
I am trying to work out whether a document can be safely stored in B & W format to reduce storage requirement.
The GIF format was nearer to the result I would have expected from the calculation ie low number of colours for a document that could be fairly represented in B & W.
It seems (to me) that saving in GIF format attempts to remove any extraneous colours whereas PNG does very much the opposite.
Testing the colour count via GIF format would seem to be the best option for me. However, getting the image in GIF format is potentially a problem. I can save to a GIF stream and then reload the GIF stream into the TImageEnView, but that takes too long for large files.
So I am wondering is there some process in TImageEnProc that will allow me more quickly to replicate the process undertaken by GIF files in relation to the colour palette (without saving to GIF format) before I call the CalcImageNumColors function?
Thanks and Happy New Year. Let's hope there's some improvement on 2020.
|
|
|
shackers
United Kingdom
28 Posts |
Posted - Jan 01 2021 : 09:11:28
|
Ah! I take it all back. It seems that there is not something clever going on with GIF files. Just tested with full colour photo saved in JPG format.
CalImageNumColors reported just under 240,000.
Converted from JPG to PNG also just under 240,000
Converted from original JPG to GIF - 99
Converted from GIF to PNG - 99
Converted from GIF back to JPG - just over 330,000.
The difference in quality (when zoomed) between the original JPG and the GIF image is very noticeable and clearly there should be a significant difference in colours. However, 99 seems on the light side even taking that difference into account.
Viewing the PNG images and JPG images that have been converted from the GIF image, the quality of these images seems to have deteriorated to the same extent as the GIF image.
Yet the JPG (not the PNG) is reporting an even higher colour count than the original JPG.
In short, I am confused. Is there a problem with GIF format for the purposes of CalcImageNumColors? If so, is there any way I can ensure I am getting a relatively accurate colour count regardless of format?
|
 |
|
|
xequte
38608 Posts |
Posted - Jan 01 2021 : 22:15:05
|
Hi
GIF has a maximum of 256 colors, so when outputting a full color image to GIF a color reduction needs to take place.
You should take a look at this demo:
\Demos\ImageEditing\Dithering\Dithering.dpr
When zooming, don't forget that if you have a ZoomFilter being used you will see an enhanced view of the image at that resolution, not the actual image.
https://www.imageen.com/help/TImageEnView.ZoomFilter.html
Nigel
Xequte Software
www.imageen.com
|
|
|
|
shackers
United Kingdom
28 Posts |
Posted - Jan 02 2021 : 04:14:07
|
| Thanks. I wasn't aware of the max colours for GIF. Do you know why ,when converting from the GIF to JPG format, it increased the number of colours from 99 to over 300K? |
|
|
|
xequte
38608 Posts |
Posted - Jan 03 2021 : 14:35:08
|
Hi
I would need to test it to be sure, but JPEG uses a lossy compression algorithm, and presumably shifts colors when saving.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
shackers
United Kingdom
28 Posts |
Posted - Jan 03 2021 : 16:33:44
|
No worries.
I'm beginning to think that calculating the number of colors using CalcImageNumColors may not on its own be safe for determining whether or not an image can safely be converted to monochrome. Are the any other ImageEn tools I could use instead or in addition to? |
|
|
|
xequte
38608 Posts |
Posted - Jan 04 2021 : 02:05:35
|
Yes, I agree. An image with many similar colors may convert well to monochrome, whereas an image with smaller number of colors but a bigger range may look awful. I'm not sure what a good solution is here.
Nigel
Xequte Software
www.imageen.com
|
|
|
|
shackers
United Kingdom
28 Posts |
Posted - Jan 04 2021 : 03:37:00
|
| OK. Thanks. Will rethink |
|
|
| |
Topic |
|
Search
CalcImageNumColors
