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.
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 am trying to script the creation of videos using ImageMagick to create some overlays which are then placed on top of a video.
If I try to use the image created by ImageMagick directly the transparency is drawn as opaque.
I have created a transparent PNG using ImageMagick draw commands. When loaded into GIMP and examined, the PNG has an alpha channel and each transparent pixel appears to have transparency: RGBA = 0,0,0,0
This image when then used as an overlay in ffmpeg just has an opaque black background in the video.
If I export the image again from GIMP then the file looks identical, but in the video just appears as a solid blue (the colour of the drawings in the overlay image).
I can fix this by taking the overlay image, loading it in GIMP and then selecting all and creating a new image from the clipboard and exporting that (using exactly the same settings as when I re-exported before without creating a new file) and it will then work exactly as desired, showing the non-transparent portions of the overlay and not showing transparent parts.
KEY QUESTION:
How can I either script the conversion that somehow occurs when creating a new file in GIMP, or (much better) not have it go wrong in the first place?
Here are the two files:
BROKEN:
WORKS:
What is the difference?
I suggest you prefix the output filename when using ImageMagick with PNG32: to force it to generate a 32-bit ber pixel image - i.e. 1 byte each for R, G, B and Alpha and hope that ffmpeg is happier with that.
convert input.png -draw ... PNG32:output.png
If you run identify -verbose (also in the ImageMagick suite) on your broken and your working images, you will see that the primary difference is that the working image has color-type=6 and bit-depth=8 whereas the broken image has color-type=3 (indexed) and bit-depth=4
I have a report that renders images (jpg) that have been collected from various sources. This works fine within the report viewer, and when exporting via Excel.
However, when exporting to PDF, about 5% of the images are rendered incorrectly as can be seen below, with the original on the left, and what is rendered on the right;
I find that if I open up one of these images in mspaint, and just click save, on the next report-run the image is now rendered correctly.
Are there any rules as to what image properties/format are valid for SSRS to render the image correctly within a PDF? Essentially I'd like to somehow find these images that will render incorrectly before the report is run and fix them prior...
Current Workaround
I never ended up getting SSRS to display the the problem images as they were, however, determining before running the report which images would be included in the non-displayable set so they could be converted to a supported format (automatically) was also a solution.
In my case, all images were supplied via users uploading to a website, so I was able to identify and convert images as they arrived. For all existing images, I was able to run a script that identified the problem images and convert them.
Identifying problem images
From the thousands of images I had, I was able to determine that the images that wouldn't render correctly had the following properties:
Image had CMYK colorspace or;
Image had extended color profiles or;
Both of the above
Converting an image
I was originally using the standard .NET GDI (System.Drawing) to manipulate images however the API is often prone to crashes (OutOfMemoryException) when dealing with images that have extra data. As such, I switched to using ImageMagick where for each of the identified images I:
Stripped the color profiles and;
Converted to RGB
Note that the conversion to RGB from CMYK without stripping the color profiles was not enough to get all images to render properly.
I ended up just doing those items on every image byte stream I received from users (without first identifying the problem) before saving an uploaded image to disk. After which, I never had the rendering problem again.
Because of the way the output looks I would say those JPEG images have CMYK colorspace but the SSRS assumes they use RGB colorspace and sets the wrong colorspace in PDF.
If you can post a JPEG image and a sample PDF I can give you more details.
I've had exactly the same problem with an image rendering correctly on screen but appearing like the one in the question when I exported the report to PDF. Here's how I solved it.
The Problem
The first clue was this article I came across on MSDN. It seems that regardless of the original image density, the PDF renderer in SSRS resizes all images to 96 DPI. If the original size of the image is larger than the size of the page (or container), then you will get this problem.
The Solution
The solution is to resize the source image such that it will fit on your page. The requires a little calculation depending on your page size and margin settings.
In my case, I'm using A4 paper size, which is 21cm by 29.7cm. However, my left margin is 1.5cm, and my right margin is 0.5cm, for a total inner width of 19cm. I allow an extra 0.5 cm as a margin of error, so I use an inner width of 18.5cm.
21 cm - 1.5 cm - 0.5 cm - 0.5 cm = 18.5 cm
As noted before, the resolution generated by the PDF renderer is 96 DPI (dots per inch). For those of us not in the United States or Republic of Liberia, that's 37.79 DPC (dots per centimetre). So, to get our width:
18.5 cm * 37.79 dpc = 699 pixels
Your result may be different depending on (1) the paper size you are using, and (2) the left and right margins.
As the page is higher than it is wide, we need only resize the width while keeping the image proportional. If you're using a paper size which is wider than it is tall, you'd use the length instead.
So now open the source image in Paint (or your image editor of choice), and proportionally resize the image to the desired width (or length) in pixels, save it, import it into your container, and size the image visually with respect to the container. It should look the same on screen, and now render correctly to PDF.
This is an issue reported to Microsoft Connect.
From SSRS 2008 How to get the best image quality possible?:
The image behavior you see in PDF is a result of some image conversions that the PDF renderer does, based on how the PDF specification requires that serialize images into PDF.
We know it's not ideal, and we classify the loss of image quality as a product issue. Therefore, it's difficult to really say what to do to get the best quality image.
Anecdotally, I have heard that customers have good results when the original image is a BMP
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'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.