In Cocoa application I've got 16x16 and 32x32 #2x version of an image: . When the image is displayed in NSImageView Mac OS X always picks higher-resolution version (i.e. downscales the #2x image on non-retina displays instead of using the 1:1 version).
(IB on the left = good, running app on the right = downscaled mess)
Of course I've got both images added to the project (as image.png and image#2x.png).
If I delete the #2x image from app bundle then OS X will display the lower-resolution image.
The bug happens regardless whether Xcode (4.6.2) combines them into a .tiff or not (and I've checked that the combined .tiff contains both images).
Oddly this happens only with this particular image. Other 1x/2x images in the same project are displayed correctly matching screen DPI.
How is that possible?! Do images have to meet some special criteria other than size and filename pattern?
Mystery solved: OS X doesn't like mixed types of PNGs.
$ file *.png
image.png: PNG image data, 16 x 16, 8-bit gray+alpha, non-interlaced
image#2x.png: PNG image data, 32 x 32, 8-bit colormap, non-interlaced
if both files are forced to use same color mode (i.e. both gray or both paletted) then OS X selects images correctly.
It turns out to be the NSImage’s prefersColorMatch property [1]:
The default value is YES. Both color matching and resolution matching may influence the choice of an image representation.
It is possible to set to NO in User Defined Runtime Attributes in Interface Builder [2].
[1] https://developer.apple.com/documentation/appkit/nsimage/1520010-preferscolormatch
[2] Are specific PNG compression types incompatible with macOS Cocoa apps?
Related
I'm updating an existing macOS app with new images.
One of them is a vector image in PDF format. When I add the PDF to an image set, Xcode determined a size for it:
The existing dialog has a larger image, so this new one renders smaller. However, I should be able to scale it to whatever size I like as it's a vector image.
It seems the size comes from metadata in the PDF file. The Inspector in Preview shows:
Are there tools I can use to tweak those values? I don't want to resample the PDF or use tools like ImageMagick - as I said, this is a vector image.
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 two images, one image is 320 x 480 called image.png and while the other is 640 x 1096 called image#2x.png. Will my app get rejected for not being exactly twice as big as the original? I have no choice it would seem if I need to fit the image on iPhone 5. Any tips or suggestions will be most appreciated.
Your naming convention is incorrect.
There is a strict rule of image file naming.
For iPhone 3G/3GS with resolution 320x480, your image should be named as image.png
For iPhone 4/4S with resolution 640x960, your image should be named as image#2x.png
For iPhone 5 with resolution 640x1136, your image should be named as image-568h#2x.png
This question is a duplicate of --> iPhone 5 - what naming convention the new images have to follow?
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.