I have a satellite image in GTiff with a range of 0 - 65535 which I need to convert to Byte format (0-255).
using:
gdal_translate [-a_nodata 0 and -scale 0 65535 0 255] -ot Byte infile.if outfile.tif
This works fine but I get a lot of pixels which are rounded down (truncated) to 0, which is my nodata value, this means that they become transparent, when it is visualized.
I have tried playing around with -a_nodata 0 and -scale 1 65535 0 255, but I haven't been able to find a solution that works for me.
What I'm looking for is getting 0 as nodata and 1-255 as the data range.
If anybody else stumbles onto this, I would just like to post the solution I found.
The routine gdal_calc.py, which enables one to use Python functions from e.g. numpy and math, can do the trick easily.
gdal_calc.py -A inputfile.tif --outfile=outputfile.tif --calc="A/258+1" --NoDataValue=0
Then one just needs to convert it to Byte format by gdal_translate og gdalwarp (if one needs to re-grid the data as well).
Related
I have a PDF file with a grayscale image that I'm trying to convert to monochromatic bitmap (1 bit per pixel) using ghostscript. I can get everything to work fine, but I don't like the way the default grayscale conversion looks with coarse lines going through it. My understanding is that I can customize the halftone algorithm to my liking, but I can't seem to get the postscript commands to have an effect on the output. Am I using the 'sethalftone' command incorrectly? Is there a different approach I should consider?
gs -sDEVICE=bmpmono -sOutputFile=test.bmp -dBATCH -dNOPAUSE -r300 -c "<< /HalftoneType 1 /Frequency 40 /Angle 0 /SpotFunction {pop}>> sethalftone" -sPageList=1 input.pdf
I can completely remove the "-c" command line parameter and it makes no difference.
This is what the current mono conversion looks like that I'm trying to improve upon:
Using the default halftone built into Ghost Script has a limited working range and a tendency to provide an appearance leaning to one side, (it is deliberate design not accidental) there is a dither control but that tends to work effectively at r/20 to r/5 in this case showing -dDITHERPPI=25 to -dDITHERPPI=60 thus reducing the blocks in size. However there are other potential controls.
I am no expert on how these settings are best used (plagiarized) we would need to read the PS manual, or play with their values, but they seem to fare better.
gswin32c -sDEVICE=bmpmono -r300 -o out.bmp -c "<< /Frequency 133 /Angle 45 /SuperCellSize 36 /Levels 255 >> .genordered /Default exch /Halftone defineresource { } settransfer 0.003 setsmoothness" -f ../examples/text_graph_image_cmyk_rgb.pdf
(note you may wish to include -dUseFastColor before -c "....)
Changing values
/Angle common values may be 0 (0=GS default) 22 30 45 52 60 67 however /Angle 45 is most common for this mono conversion, and variations coupled with a range of /Frequency (Line Screen Frequency ~= LPI) and SuperCell size may produce unachievable or sub normal result.
/Frequency (75=GS default) can be set to different values but a common ratio is 4/3 = 133 (%) another is 170 however a rule of thumb is r/2 thus if your using 300dpi /Frequency 150 may be better in this case. The correct choice is down to a complex consideration of factors, so your grid at 45 degrees is spaced at sqrt(2)=1.41421356237 at an angle. Thus the horizontal & vertical effect is 0.7071....(in terms of page dpi) thus to match 300 dpi the LPI frequency needs to be possibly made relative so consider 212
/SuperCellSize eludes me Integer; default value = 1 -- actual cell size determined by Frequency, Angle, H/V Resolution. A larger value will allow more levels to be attained. Unclear as to what may be optimum without sample of target, so try a few values but some will trigger error feedback try around 32 or 64 as a reasonable max start point. note example uses 36 ?
To prevent the undesirable moire patterns, Peter Fink proposed the Supercell Method named the Adobe Accurate Screen to realize the screen
angle having RT with the required accuracy.3 The supercell designed in the image domain including m × m (m: integer) identical halftone cells is one solution to approximate accurately the required screen angle and screen ruling. https://www.imaging.org/site/PDFS/Papers/1998/PICS-0-43/668.pdf
You may also wish to try
/DotShape Integer; default value = 0 (CIRCLE). Other shapes available are:
1=REDBOOK, 2=INVERTED, 3=RHOMBOID, 4=LINE_X, 5=LINE_Y, 6=DIAMOND1, 7=DIAMOND2, 8=ROUNDSPOT,
These values and more can be found at https://ghostscript.com/doc/current/Language.htm
Upper Left is a mono area dithered in a graphics app where depending on resolution and density "worms" or "moire" patterns start to appear. To regulate such effects a deliberate screen is applied and at smallest units aberration's in the linework pattern will not be noticeable, unless zoomed beyond intended scrutiny.
gswin32c -sDEVICE=bmpmono -r300 -o out.bmp -c "<< /Frequency 106 /Angle 45 /SuperCellSize 64 /Levels 255 >> .genordered /Default exch /Halftone defineresource { } " -f test.pdf
Imagemagick can use custom halftones, defined by XML files, so if you can't get the result you need directly with GhostScript, another option is to use GhostScript to output a high-resolution greyscale image, and use Imagemagick to produce the black and white halftoned image.
i'm using Omnivision ov5620
http://electronics123.net/amazon/datasheet/OV5620_CLCC_DS%20(1.3).pdf
this is datasheet.
than, you can see the Output Format 10-bit digital RGB Raw data.
first, i know RGB raw data is bayer array.
so, 10-bit RGB mean each channel of 1024 scale? range is 0~1023?
or 8-bit RGB each channel and four-LSB[2:0] is new fifth pixel data?
please refer the image
which is correct?
They pack every four adjacent 10-bit pixels (0..1023) of the line into 5 sequential bytes, where each of the first 4 bytes contains the MSB part of the pixel, and the 5th byte contains LSBs of all four pixels packed together into one byte.
This is convenient format because if you want to convert it to RGB8 you just ignore that fifth byte.
Also each displayed line begins with the packer header (PH) byte and terminates with the packer footer (PF) byte. And the whole frame begins with the frame start (FS) byte and terminates with the frame end (FE) byte.
I've started editing the RaspiStillYUV.c code. I eventually want to process the image I receive, but for now, I'm just working to understand it. Why am I working with YUV instead of RGB? So I can learn something new. I've made minor changes to the function camera_buffer_callback. All I am doing is the following:
fprintf(stderr, "GREAT SUCCESS! %d\n", buffer->length);
The line this is replacing:
bytes_written = fwrite(buffer->data, 1, buffer->length, pData->file_handle);
Now, the dimensions should be 2592 x 1944 (w x h) as set in the code. Working off of Wikipedia (YUV420) I have come to the conclusion that the file size should be w * h * 1.5. Since the Y component has 1 byte of data for each pixel and the U and V components have 1 byte of data for every 4 pixels (1 + 1/4 + 1/4 = 1.5). Great. Doing the math in Python:
>>> 2592 * 1944 * 1.5
7558272.0
Unfortunately, this does not line up with the output of my program:
GREAT SUCCESS! 7589376
That leaves a difference of 31104 bytes.
I figure that the buffer is allocated in fixed size chunks (the output size is evenly divisible by 512). While I would like to understand that mystery, I'm fine with the fixed size chunk explanation.
My question is if I am missing something. Are the extra bytes beyond the expected size meaningful in this format? Should they be ignored? Are my calculations off?
The documentation at this location supports your theory on padding: http://www.raspberrypi.org/wp-content/uploads/2013/07/RaspiCam-Documentation.pdf
Specifically:
Note that the image buffers saved in raspistillyuv are padded to a
horizontal size divisible by 16 (so there may be unused bytes at the
end of each line to made the width divisible by 16). Buffers are also
padded vertically to be divisible by 16, and in the YUV mode, each
plane of Y,U,V is padded in this way.
So my interpretation of this is the following.
The width is 2592 (divisible by 16 so this is ok).
The height is 1944 which is 8 short of being divisible by 16 so an extra 8*2592 are added (also multiplied by 1.5) thus giving your 31104 extra bytes.
Although this kindof helps with the size of the file, it doesn't explain the structure of the YUV output properly. I am having a look at this description to see if this provides a hint to start with: http://en.wikipedia.org/wiki/YUV#Y.27UV420p_.28and_Y.27V12_or_YV12.29_to_RGB888_conversion
From this I believe it is as follows:
Y Channel:
2592 * (1944+8) = 5059584
U Channel:
1296 * (972+4) = 1264896
V Channel:
1296 * (972+4) = 1264896
Giving a sum of :
5059584 + 2*1264896 = 7589376
This makes the numbers add up so only thing left is to confirm if this interpretation is correct.
I am also trying to do the YUV decode (for image comparisons) so if you can confirm if this actually does correspond to what you are reading in the YUV file this would be much appreciated.
You have to read the manual carefully. Buffers are padded to multiples of 16, but colour data is half-size, so your image size needs to be in multiples of 32 to avoid problems with padding breaking external software.
I'm trying to add a monochromatic noise to an image similar to Photoshop version using command line however I can't see any option to achieve it.
I've created a code in JS that does it very well and the logic here is very simple:
Foreach pixel:
Generate random noise pixel
Add or subtract (random) noise pixel to/from original pixel
The create a monochromatic noise add/subtract are on a pixel not channel basis e.g.
Pi - original pixel
Pr - noise pixel
MonoPixel = Pi+Pr or Pi-Pr
Is there any way I can randomly add or subtract pixels via command line ?
Thanks
You can use the ImageMagick +noise command to add noise. To get monochromatic noise, you'll have to do something more complex where you create a separate noise image combined with a base color and composite that with your source image.
This link may be helpful: http://brunogirin.blogspot.com/2009/09/making-noise-with-imagemagick.html
You could try and build your own little shell function. Use $RANDOM (Bash environment variable which returns a random integer in the range 0..32767) and see if it is an odd or an even number. Make odd to mean + and even to mean -.
echo $(($RANDOM % 2))
should return 1 ($RANDOM was odd) or 0 ($RANDOM was even) in random order...
I want to know how much data can be embedded into an image of different sizes.
For example in 30kb image file how much data can be stored without distortion of the image.
it depends on the image type , algoridum , if i take a example as a 24bitmap image to store ASCII character
To store a one ASCII Character = Number of Pixels / 8 (one ASCII = 8bits )
It depends on two points:
How much bits per pixel in your image.
How much bits you will embed in one pixel .
O.K lets suppose that your color model is RGB and each pixel = 8*3 bits (one byte for each color), and you want embed 3 bits in one pixel.
data that can be embedded into an image = (number of pixels * 3) bits
If you would use the LSB to hide your information this would give 30000Bits of available space to use. 3750 bytes.
As the LSB represents 1 or 0 into a byte that gets values from 0-256 this gives you in the worst case scenario that you are going to modify all the LSBs distortion of 1/256 that equals 0,4%.
In the statistical average scenario you would get 0,2% distortion.
So depends on which bit of the byte you are going to change.