The default Geoserver WMS implementation allows an output of png tiles with up to 256 Colors defined by a SLD style definition.
In conjunction with a GLSL approach to color tiles client side, I want to render tiles with more then 255 colors. Instead using the full RGB range (256 * 256 * 256) is what would be needed.
Is Geoserver or an alternative Tile generating server solution able to render 24 bit png images?
When I download the PNG from my GeoServer, it has RGB color profile:
curl -o layer.png http://localhost:8080/geoserver/test/wms?service=WMS&version=1.1.0&request=GetMap&layers=test%3Amunicipalities&bbox=498306.7970000002%2C5235854.617999479%2C855882.5630006271%2C5602020.779999593&width=749&height=768&srs=EPSG%3A25832&styles=&format=image%2Fpng
gdalinfo layer.png
[...]
Band 1 Block=749x1 Type=Byte, ColorInterp=Red
Band 2 Block=749x1 Type=Byte, ColorInterp=Green
Band 3 Block=749x1 Type=Byte, ColorInterp=Blue
Only when I explicitly request format=image/png8, I get a 1 Byte paletted PNG:
gdalinfo layer8.png
[...]
Band 1 Block=749x1 Type=Byte, ColorInterp=Palette
Color Table (RGB with 255 entries)
0: 0,0,0,255
[...]
254: 255,255,255,255
You can also request format=image/tiff if that helps you more.
See WMS output formats documentation for the full list.
Lastly, would it help you to request vector tiles and do the rendering completely on the client side?
Related
In my rails app, i let the user upload images to use as thumbnails for resources they've made. I do all the image processing with imagemagick's convert command: i convert to jpg, letterbox it to 800x600px and then make some smaller thumbnail versions of that.
This is all working fine. The problem is that some images that have come off my iPhone, for example, have the wrong orientation. My desktop seems to variously deal with this: when i see the tiny thumbnail for the image in the file chooser dialog, it's got the wrong orientation, but if I open it in the image viewing tool, it's got the correct orientation.
Presumably there's some header or metadata or something in the image file which tells the app that it needs to rotate the file? I think that I need to read this in before I do any other processing of the image, so that I can rotate the image (if necessary) before doing all the other stuff.
Can anyone tell me how I can do this, in bash on an Ubuntu server?
thanks, Max
EDIT: a bit of googling suggests that this is to to with EXIF headers...
It's true that you will have to look for orientation value reading Exif metadata of Image. Using imagemagick you can get this value by
identify -format '%[exif:orientation]' <Path to Image>
//or by using
identify -format '%[orientation]' <Path to Image>
Exif Orientation values range from 1 to 8 and maps to orientation as below:
1 = Horizontal (normal)
2 = Mirror horizontal
3 = Rotate 180
4 = Mirror vertical
5 = Mirror horizontal and rotate 270 CW
6 = Rotate 90 CW
7 = Mirror horizontal and rotate 90 CW
8 = Rotate 270 CW
Thus, image would require orientation correction if this metadata tag returns with a non 1 value. If this tag returns with no value it can be assumed to be having normal orientation.
To correct orientation to normal you can use following command
convert -auto-orient <inputImagePath> <outputImagePath>
Try
identify -format "%f %[EXIF:Orientation]" <imagename>
This gives a number from 1 to 8. These numbers are documented here
I have a 2-pixel PNG image with the following rgba:
image.setAt(0, 0, { red:255, green:10, blue:10, alpha:100 });
image.setAt(1, 0, { red:255, green:255, blue:55, alpha:255 });
image.setAt(0, 1, { red:90, green:10, blue:65, alpha:250 });
image.setAt(1, 1, { red:60, green:255, blue:0, alpha:14 });
(using node's pngjs-image module)
When the image is loaded by the browser (firefox) and copied to canvas to test the rgba data, the following is returned:
255 7 7 100
255 255 55 255
89 9 64 250
54 255 0 14
It seems like only Alpha channel values are preserved while pixel colors are arbitrarily changed.
What's going on?
(using Firefox 41 on Linux)
EDIT
From intro on pngtoy nodejs module I have found the following:
Low-level implementation of PNG file parser/reader/decoder using
JavaScript on client size.
Why this when browsers support PNG already?
The browser will simply load and convert any PNG type into RGBA
bitmaps. It will also apply ICC and gamma correction to the image
resulting in different values than in the original bitmap.
However, I thought that PNG itself should have ICC and Gamma correction chunks so that the browser applies them. Does the browser make such image manipulation to any png file even without ICC/gamma chunk inside the file?
Firefox converts images with alpha to pre-multiplied alpha for internal use. If your workflow is recovering the image from Firefox' internal image buffer, there will be loss of precision when reversing the pre-multipled alpha. In the extreme, pixels with alpha equal to zero will be returned as transparent black, regardless of the underlying color in the original PNG. This effect doesn't depend upon whether color management chunks are present or not.
Note that this doesn't happen when you click on a PNG image and "save as..."; in this case the original PNG is returned.
Firefox may also modify the internal image (depending upon the setting of gfs.color_management.mode in "about:config") when color management chunks (iCCP, sRGB, gAMA, and/or cHRM) are present, but that does not seem to be the case for this particular question. Again, "save as..." will return the original pixels and the color management chunks unchanged.
I have an obscure raster image file format called RVG. It is created from Kodak's carestream sensor. I want to be able to open it for viewing through web software(ruby/rails). We have RMagic installed and use it for other images but this format is not supported. This is the file information for a sample image:
MediaStorage is 1.2.840.10008.5.1.4.1.1.1.3.1 [Digital Intra-oral X-Ray Image Storage - For Processing]
TransferSyntax is 1.2.840.10008.1.2.4.70 [JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1]): Default Transfer Syntax for Lossless JPEG Image Compression]
NumberOfDimensions: 2
Dimensions: (1200,1600,1)
SamplesPerPixel :1
BitsAllocated :16
BitsStored :12
HighBit :11
PixelRepresentation:0
ScalarType found :UINT16
PhotometricInterpretation: MONOCHROME2
PlanarConfiguration: 0
TransferSyntax: 1.2.840.10008.1.2.4.70
Origin: (0,0,0)
Spacing: (0.0185,0.0185,1)
DirectionCosines: (1,0,0,0,1,0)
Rescale Intercept/Slope: (0,1)
Orientation Label: AXIAL
Is there a way to read this image and export as jpg? I understand that Raster Images are basically a grid with color information. Maybe I can read line by line and export?
I'm trying to place a png image on a postscript document for conversion to a pdf file using Ghostscript (v 9.15) ps2pdf. I've found that the following code works nicely with a jpg file, but I need to import png files instead. It looks like i must need a different filter, but I can't find one that works. Does anyone have a solution?
239 % number of pixels in the horizontal axis
67 % number of pixels in the vertical axis
8 % bits per color channel (1, 2, 4, or 8)
[239 0 0 -67 0 67] % transform array... maps unit square to pixel [ w 0 0 -h 0 h ]
(My_Logo.jpg) (r) file % see page 587 and page 77 for more details
/DCTDecode filter % see page 589
false % pull channels from separate sources
3 % 3 color channels (RGB)
colorimage % see page 544 and page 288 for more detail
PostScript doesn't support PNG directly, it does support JPEG which is why your code above works.
If you want to read image data from a PNG file you will need to open the file, strip the header, then read each chunk individually parsing the data from it. It might be easiest to write the bitmap data to an intermediate file, but its perfectly possible to write a stream decoder to supply the data as required for a procedural image data source.
Fortunately PostScript (level 3 for certain, most versions of level 2) does support Flate, so you don't have to write the decompression code in PostScript, you can use the filter directly.
You will need to specify a colour space, depending on whether the PNG uses a palette or not.
PostScript is a programming language, so this is all possible, it will take an experienced PostScript programmer a couple of days to write and debug it I should think.
NOTE! PostScript does not support transparency, so you cannot apply alpha channels from PNG files at all.
I am trying to save a JPEG image onto the disk using imwrite, seems that I am missing something. I am always getting a black image of around 4KBs. What am I doing wrong here?
Image I see seems fine but once onto the disk, its completely black.
std::vector<int> qualityType(1);
qualityType.push_back(CV_IMWRITE_JPEG_QUALITY);
cv::imwrite("Final.jpg",image,qualityType);
The following code works for me on 8bit (1 and 3 channel) images:
std::vector<int> qualityType;
qualityType.push_back(CV_IMWRITE_JPEG_QUALITY);
qualityType.push_back(90);
cv::imwrite("Final.jpg",image,qualityType);
In your code qualityType is initialized incorrectly. Your vector contains 2 values
{<some unknown number>, CV_IMWRITE_JPEG_QUALITY}
but should be
{CV_IMWRITE_JPEG_QUALITY, <desired quality value>}
imwrite prints on a 0 to 255 scale, but your image is in a 0 to 1 scale. To scale up, use this line:
image.convertTo(image, CV_8UC3, 255.0);
I only had to convert it to 16bit image
image.convertTo(image,CV_16UC3,255,255);
as per document, 8 or 16 bit images can be saved.