I am working on a website right now. Sadly the png logo and as well the background which uses the same colors is displayed on some computers with Firefox in lila. With Chrome the blue looks as expected.
The used monitor also has an effect, but with Chrome everything looks fine.
Where does that issue come from, and how can I fix that?
Here is my image
Here you see a photo of my monitor. The lila with firefox (on the left) is visible slightly. The big issue is that the color is used in the background of my website, which looks lila than, with firefox, and the displayed color does not match the other colors in css at my website anymore.
The above picture is from firefox:
The above picture is from chrome:
Firefox handles images that contain an sRGB profile slightly differently from untagged images and HTML colors, by default. It has three modes of operation that you can select by going to "about:config", searching for gfx.color_management.mode. The default is "2". Change it to "0" (no color management) or "1" (color manage everything) and you'll get a good match.
See the four-year-old bug #621474 at https://bugzilla.mozilla.org and scroll down to comment #49 to see current status of the patch.
Because of these differences (you can't control which setting people use), it's probably best to just remove the iCCP chunk or sRGB chunk from your image. Browsers will assume the image is in the sRGB colorspace and display it properly against HTML colors.
"pngcheck" says you have iCCP and cHRM chunks:
$ pngcheck -v so-logo.png
File: so-logo.png (147985 bytes)
chunk IHDR at offset 0x0000c, length 13
506 x 171 image, 32-bit RGB+alpha, non-interlaced
chunk pHYs at offset 0x00025, length 9: 2835x2835 pixels/meter (72 dpi)
chunk iCCP at offset 0x0003a, length 2639
profile name = Photoshop ICC profile, compression method = 0 (deflate)
compressed profile = 2616 bytes
chunk cHRM at offset 0x00a95, length 32
White x = 0.31269 y = 0.32899, Red x = 0.63999 y = 0.33001
Green x = 0.3 y = 0.6, Blue x = 0.15 y = 0.05999
chunk IDAT at offset 0x00ac1, length 145212
zlib: deflated, 32K window, maximum compression
chunk IEND at offset 0x24209, length 0
No errors detected in so-logo.png (6 chunks, 57.2% compression).
There are various tools you can use to remove those chunks:
pngcrush (also removes the pHYs chunk):
pngcrush -rem alla -force logo.png logo_crushed.png
pngsplit+cat:
pngsplit logo.png
rm logo.png.0003.iCCP
rm logo.png.0004.cHRM
cat logo.png.00*.* > logo_split_cat.png
PNG files include ICC color profile metadata. Some browsers ignore this metadata and display the image as if its bits represent an sRGB image. Other browsers take into account the ICC colorspace and make the appropriate color transformations before outputting to the display. If the PNG uses the sRGB color profile, it should look the same in all browsers. However, if your PNG has some other color profile (such as AdobeRGB), then perhaps Firefox is not compensating whereas Chrome is. In this case, the Firefox image is technically displayed incorrectly, although it will match RGB font colors in your HTML, whereas the Chrome image is displayed "correctly" (i.e. to the creator's original intent for the colors) but will not match the RGB font colors in your HTML (which are specified in sRGB).
Bottom line, check the ICC colorspace of your PNG.
Related
I've got an RTF file with an embedded image in it. The image is scaled by 2/3, or 0.67. It displays correctly in Word, but when the file is printed it consistently displays by ignoring the scale setting.
The source image is a PNG with dimensions 297x117 (pixels). The image was originally encoded as follows:
{\pict\pngblip\picw7858\pich3096\picwgoal4455\pichgoal1755\picscalex67\picscaley67
<Hex-encoded PNG image>}
The original picture width/height is calculated as (w,h) * 2.54 * 1000 / 96 (twips).
The original picture width/height goal is calculated as (w,h) * 1440 / 96 (twips).
A twip is 1/1440 inch and 2.54 is the number of centimetres in an inch.
I edited it to try setting the size manually. I multiplied all of these values by 2/3 and removed the \picscale[xy]67 instructions:
{\pict\pngblip\picw5239\pich2064\picwgoal2985\pichgoal1176
<Hex-encoded PNG image>}
However, it still seems to only use the size of the PNG (297x117) when printing it. The screen display and the print result both appear unchanged from before.
Other than manually rescaling the image and re-embedding it into the RTF, can I get the printed version to respect the scaling?
UPDATE
I did try embedding an image resized to 2/3 of the previous dimensions, but the printed image is still 50% larger than the on-screen image (the extra area gets cropped). The only difference is that it was much lower resolution.
I also tried the same image in a Word document and it printed perfectly, so it's definitely a difference between .docx and .rtf files. Is it perhaps a dpi setting in the PNG image?
Windows 10 updated itself last night, and now I can't replicate the problem. All old files that previously had this problem, no longer have this problem. Go Microsoft!
It appears to be this update that resolved the issue: https://support.microsoft.com/en-au/help/4093112/windows-10-update-kb4093112
Addresses an issue with printing content generated by ActiveX in Internet Explorer
There's no more information about this, but it is related to printing.
I started using the ionicons_2-0-1_ios-pause-outline and
http://fa2png.io/r/ionicons/
to convert these to the correct size.
However when I try the iOS iPhone 7 simulator I get this message:
Warning: Input PNG does not have an 8 bit input depth. Please convert
your PNG to 8-bit for optimal performance on iPhone OS
How can I convert icons to png with the correct depth?
Your images are not in 8-bit, images need to be in 8-bit, not 16-bit.
That goes for the icon as well. and iOS only supports 8-bit images as well.
8-bit means 8-bits per color channel, which is 16.7 million colors.
16 bits per channel give 32,769 colors per channel, which is actually 281 trillion possible colors! 16-bit is only used for photo editing,
images still need to be saved back down to 8-bit for printing.
MakeAppIcon is useful website for generating App icons. and IcoFX is a fantastic tool for creating 8-bit depth icon.
The main difference between an 8 bit image and a 16 bit image is the amount of tones available for a given color. So your image has too many colors in it. Here's a list of some applications that can solve this problem for you. http://myappmag.com/make-windows-icons/ from that list; Number 5 seems to be a good option.
Also this can help you find a color within the 8-bit range.
http://neildowning.com/HEX_to_RGB_color_converter.php
Looks like Xamarin requires 8-bit per color channel
(8-bit for Red, 8-bit for Green, and 8-bit for Blue)
http://forums.gamesalad.com/discussion/comment/61399/#Comment_61399
That is called "true color" which is actually PNG-24 (because 24 = 8*3)
https://en.wikipedia.org/wiki/Color_depth#True_color_.2824-bit.29
So why don't we run a python script to do that for us.
If you are not familiar with python, all you need to do is
Download Python (make sure you add pip to your path during setup)
run pip install pillow in the cmd (Run as Administrator if says Access is denied)
. Pillow is an imaging library for python.
Make a file in the folder with your images, call it convert.py
Put the following in it
def convert_to_24(image_file):
from PIL import Image
try:
im = Image.open(image_file)
except(FileNotFoundError):
print(image_file ,"was not found.")
return
print(image_file,"is in",im.mode,"mode.")
if im.mode != "RGB":
im = im.convert("RGB")
im.save(image_file.split('.')[0]+"_24.png")
return
if __name__ == "__main__":
convert_to_24(input('Enter image file name:'))
Open cmd where the script and the images are and type python convert.py
When it asks for the file name, put the file name including the extension, like filename.png
It will tell you in what mode the image was, and will create another image with a name filename_24.png that has 8-bit color pixels (aka 24bit png).
How can I convert icons to png with the correct depth?
Convert to jpg and back to png. That will also remove the alpha (transparency) channel.
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'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'm having trouble viewing a file that is declared to be a TIFF HDR image by Hugin.
Windows Explorer "Properties => Details" states that the bit-depth of the image is 128
Windows Explorer shows it as a white image.
I've tried converting the image to JPEG via ImageMagick, white image.
Picasa Image Viewer says "Invalid image".
I've tried opening it in Photoshop CS5, white image.
These are the stiching options set in Hugin; http://i.imgur.com/vmzA9.png
These is the Images tab in Hugin; http://i.imgur.com/33ySq.png
This is the entire output of Hugin; http://i.imgur.com/smV6O.png
Here is the complete TIFF _hdr file; http://c759972.r72.cf0.rackcdn.com/DSC_3873-DSC_3875_hdr.tif Size: 64 MB
So, is the problem that I'm not viewing it in the correct mode -- or that it really is a white image?
I imported your image using Mathematica. After import, it appears white. That is because the pixel values are not scaled properly: The maximum value is 1070 whereas any value greater than 1 is displayed as white. When rescaling the values to run in the range from 0 to 1, one can see the following:
In[64]:= image = Import["http://c759972.r72.cf0.rackcdn.com/DSC_3873-DSC_3875_hdr.tif"];
In[65]:= ImageType[image]
Out[65]= "Real32"
In[66]:= Max[ImageData[image]]
Out[66]= 1070.
In[67]:= ImageAdjust[image]
Either the image file is indeed corrupted, or the various programs can't read it. Anyway, the image is not white. There seems also to be some mis-alignment between the poses that were used to create the HDR.