I'm trying to write a TIFF image with RMagick that tesseract can process. Tesseract objects if bits per pixel is > 32 or samples per pixel is other than 1, 3 or 4.
With the defaults, Image.write generates 3 (RGB) samples plus 1 alpha channel at 16-bits per sample for a total of 64 bits per pixel, violating the first constraint.
If I set the colorspace to GRAYColorspace as follows, it still outputs the alpha channel, giving two samples per pixel, violating the second constraint.
Image.write('image.tif) {self.colorspace = GRAYColorspace}
Per the RMagick documentation, the alpha channel is ignored on method operations unless specified, but even if I do self.channel(GREYChannel), the alpha channel is still output.
I know I can run convert on the file afterwards, but I'd like to find a solution that avoids that.
Here is the tiffinfo output for the file currently generated:
TIFF Directory at offset 0x9c48 (40008)
Image Width: 100 Image Length: 100
Bits/Sample: 16
Compression Scheme: None
Photometric Interpretation: min-is-black
Extra Samples: 1<unassoc-alpha>
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 2
Rows/Strip: 20
Planar Configuration: single image plane
Page Number: 0-1
DocumentName: image-gray-colorspace.tif
White Point: 0.3127-0.329
PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
Related
I use the following minimal PostScript file:
%!PS-Adobe-2.0
%%BoundingBox: 0 0 100 100
0 0 moveto 100 100 rlineto stroke
showpage
This draws a line from (0,0) to (100,100) in a 100x100 box.
I then convert this file minimal.ps to a PNG with this command line, borrowed from GhostScript's documentation:
gs -sDEVICE=pngmono -o minimal.png minimal.ps
With GPL Ghostscript 9.53.3 (current Debian stable) and 9.27 (oldstable) the resulting PNG file has the following dimensions:
> identify minimal.png
minimal.png PNG 612x792 612x792+0+0 8-bit Gray 2c 2994B 0.000u 0:00.000
Both width and height extend far beyond the original BoundingBox, and they are not even equal.
The PNG's dimensions are the same if the output device is pnggray, pngalpha, etc.
The dimensions are also the same if, in the PostScript code, 100 is replaced by 10 or by 10000.
How can I tell GhostScript to create a PNG file whose dimensions automatically fit the PostScript file's BoundingBox?
I don't understand :
if we considerate the value 00001111 (15) is a byte and a RGB pixel (220,180,155) it's 3 bytes whatever the values of the pixel.
so why when i reduce the values of my pixels (with bitshift operation or whatever) the size of
my image is not = pixel numbers x 3. when i say "pixel numbers" i mean "pixel numbers bigger than fully black".
how the mechanism works ? is it counted in bits and then divided by eight as an average ?
if i have a 3MB picture and i do a bitshift (factor 2 on each 3 RGB channel) i found a 300 KB picture.
Don't tell me 90% of my pixels turned fully black.
Thanks.
If you shift all the pixel values right by 2 places, you will have around 1/4 as many shades of red as before, and around 1/4 as many greens and likewise for blues. That means overall you will have vastly fewer colours. That means your image may well have fewer than 256 colours which means it can be palettised. It also means it is likely to compress better because there will be more repetition of fewer unique sequences.
You can check if your image is palettised in several ways:
open it with PIL and check if image.mode contains a P
run exiftool on it and check if Colour Type is Palette
run ImageMagick on it with magick identify -verbose YOURIMAGE
You can count the number of unique colours in your image with ImageMagick using:
magick identify -format %k YOURIMAGE
Or you can do it in Python with the last part (entitled "Update") of this answer.
I am trying to write a sequence of color images to a dicom file in Matlab. Each image is of type uint16. The sequence is stored in a 4D matrix named output of size 200x360x3x360 (num of rows x num of cols x num of channels x num of images). When I execute dicomwrite(output,'outputfile.dcm'), it gives the following error:
It says data bit depth is 8 but I've ensured that each image is 16-bit. Not sure what's going wrong.
The documentation for dicomwrite says it can write color images as well. In fact dicomread can read color dicom images such that the size of the matrix which stores the read data is 200x360x3x360. So I guess it should be possible to write color images as well using dicomwrite. Any help in this regard is appreciated. There is a related post but it doesn't talk about color image sequence.
The comment by JohnnyQ is correct.
From this page down in section A.8.5.4, they list the Multi-frame True Color SC Image IOD Content Constraints (partial list quote):
In the Image Pixel Module, the following constraints apply:
Samples per Pixel (0028,0002) shall be 3
Bits Allocated (0028,0100) shall be 8
Bits Stored (0028,0101) shall be 8
High Bit (0028,0102) shall be 7
Pixel Representation (0028,0103) shall be 0
It seems matlab will not do the conversion for you, so you should down convert each 16-bit color channel to 8-bit for DICOM
A 24 bit .png file with transparency, as those that can be generated with Photoshop, has really 24 bits distributed across each color plus the alpha ? or the 24 bit refer only to the colors and ignores the alpha (RGBA 8888).
Is there any tool to examine a PNG file and verify this kind of information? Does Photoshop have any options to verify or configure this?
24 bit + alpha is actually 32 bits per pixel. Meaning you have the Red, Green, Blue and Alpha channels, each being 8 bit, allowing for 256 shades per channel translating to 256 x 256 x 256 x 256 possible colour combinations. That's what the "millions of colours" and "billions of colours" mean in certain graphics and video software.
As I understand it, there are three kinds of "24 bit" pngs:
24 bits with no transparency. No alpha information, truly 24 bits per pixel.
24 bits per pixel with alpha transparency. This would be 24 bits of color information with 8 bits of alpha (allows for various levels of transparency) - 32 bits per pixel total.
24 bits per pixel with binary transparency. This would be 24 bits of color information with 1 bit of alpha (transparent or not transparent) - 25 bits per pixel total.
24 bit PNG doesn't say much. An image has a pixel format. The pixel format describes the Colorspace used (such as CMYK, RGB) and bits per channel information (i.e. how many bits are allocated to represent each channel of the colorspace in use).
Go to File > File Info > Advanced. That should tell you what you are looking for.
After dissecting the exported file myself (from Photoshop CS6), I found that the "24 bit" file generated by Photoshop is actually still 8 bit. The RGBA is still one byte per channel. The IHDR PNG chunk still says that it's 8 bits per channel.
It's an 8 bit PNG.
The exported PNG also contains about 825 bytes of useless marketing text data (per PNG image).
See the image (with the byte for "bits per channel" selected):
See the specification for more details:
http://www.libpng.org/pub/png/spec/1.2/png-1.2.pdf
CGBitmapContextCreate takes an parameter that's not very obvious to me:
For example, for a 32-bit pixel format
and an RGB color space, you would
specify a value of 8 bits per
component.
I have created 24-bit PNG files with alphatransparency, and added them to Xcode. At compile time, Xcode optimizes those PNG tiles with pngcrunch.
So, when trying to make an graphics context out of such an image file on iPhone-OS, I need to specify the bits per component.
In this case, I would say they're 4 bits per component, although I dont know if alpha counts as an component.
It's 8 bits per component:
Red:8;
Green:8;
Blue:8;
Alpha:8;
That adds up to 32 bits per pixel. Your 24-bit png with transparency is 24-bits for RGB, plus 8 bits for transparency (the 'alpha channel').