I'm working on a Sidebar Gadget and cannot get my JPEGs to show up (PNGs work). When I try to open the file by itself in IE8 it doesn't work. Firefox, of course, can open it fine.
JPEG Details:
Dimensions: 1080X900
180 dpi
Bit depth 24
Color representation: uncalibrated
I've found some things talking about the images being compressed incorrectly (?) but I haven't been able to get it working...
Any clues?
IE8 drops support for CMYK JPEG and renders them as the infamous red X without so much as a warning.
If you have ImageMagick:
identify -verbose image.jpg
will show you the image colorspace. If it's CMYK, you can convert to RGB with:
convert broken.jpg -colorspace RGB fixed.jpg
If you need to do CMYK to RGB conversion on a whole batch of JPEG-images, this command may be helpful to you:
for i in *.jpg; do convert "$i" -colorspace RGB "$i"; done
PS: If you'd like to see what is going on, just add -verbose:
for i in *.jpg; do convert "$i" -colorspace RGB -verbose "$i"; done
I had a similar issue with IE8 not displaying two JPEG images. FF, Safari, Chrome all displayed them without complaint but IE acted as if the files were not there. I have no idea what was going on, but a quick image conversion to gif or png fixed the problem. Just another in a long line of confirmations that IE sucks.
Had similar problems with existing images, which will not show up in IE8.
Problem is, as converter42 says: CMYK-Images
Convert them to RGB colorspace and all is good
The Solution with the PNG is not the best, because PNG files can be MUUUCH larger than JPGS.
If you are using photoshop for creating the jpgs. Try the below.
Open the file and go to 'Image' menu
Go to Mode
Select RGB
Save and upload to server.
This should work.
Why are you dealing with the image at 180 dpi and not the 72dpi screen resolution? At screen resolution the image will be roughly double that size. Still, the size is manageable for any browser.
When creating a gadget, you should be using PNGs for all the elements of the gadgets. Are you having issues displaying JPEG photos?
Have you looked for the yellow bar at the top of IE that blocks certain suspicious content from being loaded (popups, activex, javascript, etc.)? If it appears, try telling it to "allow".
Lastly, what are you using to compress your images to JPEG?
EDIT: If you want to do batch conversion use the batch converter in photoshop or use the Actions panel to record the conversion process for a single image, then replay the action on an entire folder. Additionally, you can save this action to a "droplet" which is a small application containing the action that you can drop an image or folder on top to.
Alternatively, if you don't fell like learning Actions, XNView is an excellent image viewer and converter that supports something like 160 different image formats and can batch convert and batch rename huge lists of files.
I fixed this issue by opening the CMYK JPEG file in Windows Paint and then saving as a JPEG, which Paint encodes as RGB by default. Not a great solution because I'm sure that Paint's converter is not as robust as Photoshop's, but this can be a quick fix if the job needs to be done now and there's no access to the tools above.
Related
I dont understand the explanation about why GIF files always has image resolution 72ppi.
I have tried using ImageMagick converting PNG to GIF specifying -density to be 300ppi, but the resulting GIF is still 72ppi.
The GIF format does not store any value for "ppi" or "dpi" or pixel density/resolution - see Wikipedia.
I think software assumes 72 dpi, and then loads your image, updating that assumption if it finds anything better... which it never will in the case of GIF.
In any case, the dpi/ppi is irrelevant until such time as you want to print your image, and I don't know of anyone ever using GIF as a method of submission of images to any reputable printers or publications - TIFF is probably the preferred or most common method.
I use Abbyy FineReader for ScanSnap to OCR a couple of scanned PDF files. The software claims it retains the original PDF images. The PDF file sizes pre-OCR and post-OCR are almost identical, which is good.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Left: Scanned PDF / Right: after OCR with Abbyy
I would like to get the original images without anti-aliasing back. Interestingly, when I open a single page from the anti-aliased PDF in Photoshop, there is no anti-aliasing and the image looks like the left one.
My limited PDF programming experience leads me to believe that Abbyy likely sets some kind of anti-alias flag for each image during OCR processing. How do I un-set this flag?
Any pointers to useful ideas would be much appreciated.
After the software is done, all PDF images appear anti-aliased in Acrobat X. Page navigation is much slower than before, and when I zoom in/out, the images first go to what looks like the pre-anti-aliasing version before quickly changing to anti-aliased images.
Actually in the original file 2013_11_15_22_51_31.pdf contains a JPEG image while the OCR'ed file 2013_11_15_22_51_31_OCR.pdf contains a JPEG2000 image.
Comparing them in third party viewers, it becomes clear that the image in the OCR'ed file is not inherently anti-alias'ed. Furthermore there is no evident flag in the PDF instructing PDF viewers to apply anti-aliasing to the JPEG2000 image. Thus, Adobe Reader seems to automatically render JPEG and JPEG2000 images differently, applying anti-aliasing to the latter but not to the former.
Comparing both images in detail, though, it becomes clear that these images are not identical but instead the image in the OCR'ed PDF is slightly rotated.
I assume Abbyy FineReader recognized that the original scanned image is not correctly oriented. Thus, it rotated it slightly to correct this orientation.
Thus, replacing the image in the OCR'ed version with the one from the original one is no option: Due to the rotation the OCR information would partially be somewhat off.
What you might want to try is to recode the JPEG2000 image to JPEG and replace the image in the OCR'ed version with this recoded one. This will mean some loss of quality but most likely you can get rid of the anti-aliasing this way.
Be aware, though, that the JPEG2000 image is slightly larger than the JPEG image to accomodate for the rotation.
PS: As #VadimR pointed out, there is indeed an /Interpolate true entry in the image dictionary of the OCR-ed version I missed when looking at the file. This does not seem to be the major issue slowing down the rendering.
There is /Interpolate true entry in image dictionary of OCR-ed version, and that's what causes 'anti-aliasing'. Whether that (and not JPEG2000 instead of JPEG compression) is a cause of slow-down, you check on large enough files.
To un-set this key, the best would be to turn it off while creating a file, and if that's not possible, to write and run a small program in suitable language.
But, since your file doesn't sport 'compressed objects' and offending key is in plain view inside a file, in the spirit of 'job done quickly' you can simply process your file e.g. like this:
perl -M-encoding -0777pe "s!/Interpolate true!' 'x17!ge" <in.pdf >out.pdf
I'm building an application which uses Ruby+RMagick to composite PNG images onto various JPEG backgrounds. Everything is working, but we have found one particular JPEG background for which the PNG is composited as a black spot. PNG transparency is respected; the shape of the "spot" is correct, but the colors are being lost and becoming black.
I have tried many JPEGs to try to find another which yields the same result, but (so far) have failed.
I suspect that it may have something to do with the bit depth or some other parameter of the JPEG file in question. I have been searching the Internet, looking for a tool which can analyze this JPEG and tell me all the parameters which might be relevant, but haven't found anything yet.
Has anything like this ever happened to you? What was the cause?
Based on your knowledge of the JPEG format, are there any other parameters which might be relevant?
Do you know of any tool which can analyze JPEG files, and tell me the bit depth and other parameters? Or if I open the JPEG in a hex editor, can you tell me how to find this information?
I still haven't found what is special about that one JPG which the composite operation doesn't work correctly on, but I worked around it using this code:
back = Magick::Image.from_blob(jpg_data).first
png = Magick::Image.from_blob(png_data).first
page1 = Magick::Image.new(back.columns, back.rows)
page1.composite!(back, 0, 0, Magick::OverCompositeOp)
page1.composite!(png, png_x, png_y, Magick::OverCompositeOp)
Rather than:
back = Magick::Image.from_blob(jpg_data).first
png = Magick::Image.from_blob(png_data).first
page1 = back.composite(png, png_x, png_y, Magick::OverCompositeOp)
Here is an image:
This image is a simple black-to-transparent gradient saved in full RGBA PNG.
Here is the same image, converted to indexed-alpha PNG by GIMP (Photoshop produces the same result)
As you can see, the gradient is now half-opaque, half-transparent.
Here is the same image again, only this time it was converted to indexed-alpha PNG by a PHP script I wrote:
So my question is: Why are GIMP and Photoshop unable to support partial transparency in indexed images, when the PHP script clearly shows that such an image can be created with no problems?
Is there anything "wrong" with an image whose pallette contains alpha information?
A more programming-related question: Does this transparency in the last image work in Internet Explorer 6?
I've finally found the actual answer: There is a metadata entry that allows you to define the alpha value of each colour in the colour table. Most graphics programs don't make use of this, but it does exist and can be used, in particular by GD.
Another option besides fireworks is pngquant, a command line application that will convert a rgba png into an indexed png with transparency.
I found this post which talks some more about how to use it.
IE6 and earlier in windows does not support variable transparency PNGs without annoying workarounds. An indexed PNG will only show the fully opaque parts which usually works pretty well. A drop shadow would disappear but the opaque parts of the logo or icon would continue to show.
This page has a better explanation and instructions with more png compression and quantization tools: http://calendar.perfplanet.com/2010/png-that-works/
For the record, PNG does not literally support indexed images with an alpha channel. What is really happening is that PNG allows you to add additional colors to the color table (i.e. index) with alpha values in those colors... not a complete alpha channel. FWIW...
Yeah I know what you mean. Fireworks is the only image editing program that I know of that can create and edit PNG8+Alpha without problems. I wish more paint programs would support this format cause Fireworks is expensive!
I found a way in GIMP to create or convert an image with reduced color palette and alpha channel.
The trick is to add a mask to the layer.
Full steps to reproduce:
Have your image in one layer
Add a mask to the layer. Select Transfer layer's alpha channel.
Convert to Indexed (Image -> Mode -> Indexed...)
Save as PNG
Now your image has reduced colors and reduced size, but it keeps your smooth transparency.
I have a jpeg that shows up properly in FF, but won't appear in IE or Chrome. I tried downloading the image and loading it in IE and Chrome directly without success: both browsers shows a broken icon. So this is not a network issue.
This file is a result of an image resize by javax.imageio.ImageIO. I have processed over 1000 images successfully.
Windows explorer shows the thumbnail properly, and I can edit it successfully in Microsoft Office Picture Manager.
Is there any tool that could help me understand what is wrong with this file?
My guess is it's a CMYK JPG. Change it to RGB.
I had the same issue several times (mostly in IE 6 and 7).
Two things I've notice (except the colorspace CMYK / RGB, witch is the first thing to look for):
Even in Photoshop, when I changed the colorspace ("mode" in PS), and re-saved the image, often the change didn't seem to stick. So I often find it easier to do a copy/paste in a fresh new RGB 8 bit document.
Also, those images usually came from a Mac PS while I was working on a PC (or vice-versa) so something regarding RGB Mac/PC colorspace seems to be at stake here.
I had a similar issue and thanks to twlichty for the correct answer to my issue. The file was a CMYK jpg format.
But I needed to keep it in CMYK as we are printing off the image as a looped background for office awards. As a solution I worked of the OP's final solution and I changed the image to PNG. I turned off Transparency as it was not needed and I unchecked Convert to sRGB to keep it in CMYK. This then created a CMYK image with a PNG wrapper that Internet Explorer was capable of printing. The final image colors look spot on as well.
Just wanted to leave my own issue and fix found related to this topic for others.
Cheers.
batty13
If all you want to do is fix this one image and move on, I imagine you could fix it by simply writing it out with a different tool, perhaps after making a trivial change.
You need a library/class that supports CMYK, otherwise all you get is an error or, even worse, all you get is an unreadable pictures.
Look your documentation for references to "Colorspace".