I am reading a particular TIF file that reports a zero scanline size. The read operation returns null.
tiff = Tiff.ClientOpen("image", Stream.Length == 0 ? "w" : "ra", Stream, new TIFFTruncStream());
tiff == null, and the log contains a Zero scanline size trace message.
The .NET framework and some other viewers cannot open the file, We have managed to open the file(s) in some older IBM viewers. Is this definitely a corrupt file or just a scenario unsupported by LibTiff.NET?
Thanks
Zero scanline size is definitely not supported by libtiff/LibTiff.Net. I do not know about any other viewer that supports images with scanlines of zero length.
Jim sent us couple of such files and it turned out that the files are corrupt/broken. They specify zero width for their first page.
I tried to open these files in some other image viewers and only Preview utility in Mac OS X Mavericks could open them. The utility opens both files but silently skips the fist broken page. It shows not errors and acts like there is one less page in the files.
To achieve the same (silently skip first page), you can use the following workaround:
Open the TIFF in append mode
Set current page to be first page
In a loop check the size of each page
Skip any page with zero width or height
Below is a sample code for the workaround.
// "a" is for append
using (Tiff inImage = Tiff.Open(put-file-name-here, "a"))
{
if (inImage == null)
return;
// move to the first page
inImage.SetDirectory(0);
do
{
FieldValue[] width = inImage.GetField(TiffTag.IMAGEWIDTH);
FieldValue[] height = inImage.GetField(TiffTag.IMAGEWIDTH);
if (width[0].ToInt() != 0 && height[0].ToInt() != 0)
{
// the page appears correct, do something with it
}
} while (inImage.ReadDirectory());
}
Related
I am using Aspose.Imaging 19.11.0.0 for manipulating the Tiff Images with Compression JPEG,
But here If I have 10MB+ sized tiff files(having 50 pages) then in this case it is taking 30 to 40 minutes to rotate these all tiff pages and application went on not responding mode.
In my code, suppose I have 50 pages in Tiff image files, then from client application I am iterating each pages through foreach loop and sending corresponding rotate method for each page on server side for rotation,
I know the one of the factor for time consuming is the sending each pages instead of all pages at once,
but when I debugged the code then found that tiffImage.Save(Stream, tiffOptions) is taking more time for each page also.
Below are the server side code for rotating the page using JPEG compression ,
Here below RotatePageUsingAspose() method is called each time for all pages,
means suppose I have selected only 3rd page out of 50 then it is being called only one time for selected page with parameter pageNumber =3 and rotation degree = 90 degree
In this case, means rotating the 3rd page and saving this page is also taking almost 1 minute,which is far too slow.
Server side code for rotation:
private void RotatePageUsingAspose(int pageNo, RotationDegrees rotationDegree)
{
float angleOfRotation = (float)rotationDegree;
// Auto mode is flexible and efficient.
Cache.CacheType = CacheType.Auto;
// The default cache max value is 0, which means that there is no upper limit.
Cache.MaxDiskSpaceForCache = 1073741824; // 1 gigabyte
Cache.MaxMemoryForCache = 1073741824; // 1 gigabyte
// Changing the following property will greatly affect performance.
Cache.ExactReallocateOnly = false;
TiffOptions tiffOptions = new TiffOptions(TiffExpectedFormat.TiffJpegRgb);
//Set RGB color mode.
tiffOptions.Photometric = TiffPhotometrics.Rgb;
tiffOptions.BitsPerSample = new ushort[] { 8, 8, 8 };
try
{
using (TiffImage tiffImage = (TiffImage)Image.Load(Stream))
{
TiffFrame selectedFrame = tiffImage.Frames[pageNo - 1];
selectedFrame.Rotate(angleOfRotation);
tiffImage.Save(Stream, tiffOptions);
}
}
finally
{
tiffOptions.Dispose();
}
}
I have raised the same question to Aspose.Imaging team but they have not provide the solution for this yet.
Kindly suggest the improvements for above code for saving the pages in efficient manner.
If possible please provide the approach to achieve this.
I have a problem with ABCPdf, when I try to convert a pdf files into seperate image files as fallbacks for old browsers.
I have some working code that perfectly renders the page and resizes the rendering into the wanted size. Now my problem occurs when the pdf page is huge w7681px x h10978px. It nearly kills my development machine and the deployment machine cannot even chew the file.
I normally just render the page 1-to-1 as the pdf page and then uses other algorithms to resize this image. This is not efficient since ABCPdf takes alot of power to output this image.
I have the following code:
private byte[] GeneratePng(Doc pdfDoc, int dpi)
{
var useDpi = dpi;
pdfDoc.Rendering.DotsPerInch = useDpi;
pdfDoc.Rendering.SaveQuality = 100;
pdfDoc.Rect.String = pdfDoc.CropBox.String;
pdfDoc.Rendering.ResizeImages = true;
int attemptCount = 0;
for (;;)
{
try
{
return pdfDoc.Rendering.GetData("defineFileTypeDummyString.png");
}
catch
{
if (++attemptCount == 3) throw;
}
}
}
I have tried the following solutions:
Resizing the page
pdfDoc.SetInfo(pdfDoc.Page, "/MediaBox:Rect", "0 0 200 300");
Resizing the page and outputting it. Which doesn't seem to make any changes at all.
Resizing the images before rendering it:
foreach (IndirectObject io in pdfDoc.ObjectSoup) {
if (io is PixMap) {
PixMap pm = (PixMap)io;
pm.Realize(); // eliminate indexed color images
pm.Resize(pm.Width / 4, pm.Height / 4);
}
}
Didn't do anything either and still resulted in a long load time.
Running the reduzed size operation before rendering:
using (ReduceSizeOperation op = new ReduceSizeOperation(pdfDoc))
op.Compact(true);
Didn't do anything either. Just went directly to rendering and took a long time.
Can anyone help me here? Maybe point me to some ABCPdf resizing algorithm or something.
Ok so I talked to the customer support at ABCPdf and they gave me the following.
doc1.Read(originalPDF);
// Specify size of output page. (This example scales the page, maintaining the aspect ratio,
// but you could set the MediaBox Height and Width to any desired value.)
doc2.MediaBox.Height = doc1.MediaBox.Height / 8;
doc2.MediaBox.Width = doc1.MediaBox.Width / 8;
doc2.Rect.SetRect(doc2.MediaBox);
doc2.Page = doc2.AddPage();
// Create the output image
doc2.AddImageDoc(doc1, 1, null);
doc2.Rendering.Save(savePath);
Which is supposed to be used with single page PDFs, so if you have a pdf full of large pictures, then you should chop it up. Which you can do following my other Q/A: Chop PDFs into single pages
The rendering algorithm they use in the above code is auto detected by ABCPdf and you cannot control it yourself (and they told me that I didn't want to). So I put my faith in their code. At least I did a test and the quality looks quite similar to a InterpolationMode.HighQualityBicubic and only differed when zoomed. So I wouldn't be too concerned with it either.
At last the above code gave me a speed boost compared to rendering and then resizing of about 10x faster. So it is really worth something if you do this operation a lot.
I tried this:
string[] files = System.IO.Directory.GetFiles(combinedsatelliteimagesdir);
NumericComparer ns = new NumericComparer();
Array.Sort(files, ns);
pictureBox1.Image = Image.FromFile(files[files.Length -1]);
But i'm getting out of memory exception on the line:
pictureBox1.Image = Image.FromFile(files[files.Length -1]);
the variable files contain 847 indexs for example the first index look like:
C:\Users\user\AppData\Local\mws\My Weather Station\satelliteImages\SatImage0.GIF
From msdn, you get OutOfMemoryException if
The file does not have a valid image format.
-or-
GDI+ does not support the pixel format of the file.
You probably reading some non-image file.
Regarding thumbs.db:
Thumbs.db is an image cache which makes thumbnail viewing faster. The file is automatically created in Windows Vista, 7 and 8 whenever images are encountered in a folder. It's usually hidden but can appear, disappear and is often impossible to delete
try this one
pictureBox1.Image = Image.FromFile(#files[files.Length - 1]);
By the way, are you sure that last file is every time a picture? No hidden "desktop.ini" or something else?
I'm using ImageMagick.NET to convert PDFs to JPGs. Here's my code:
MagickReadSettings settings = new MagickReadSettings();
settings.Density = new MagickGeometry(300, 300);
using (MagickImageCollection images = new MagickImageCollection())
{
images.Read(pdfFilePathString, settings);
MagickImage image = images.AppendVertically();
image.Format = MagickFormat.Jpg;
//image.Quality = 70;
//if (image.Width > 1024)
//{
// int heightRatio = Convert.ToInt32(Math.Round((decimal)(image.Height / (image.Width / 1024)), 0));
// image.Resize(1024, heightRatio);
//}
image.Write(tempFilePathString);
image.Dispose();
}
The problem is, I keep getting insufficient memory exceptions, which occur on the image.Write(). It is obviously due to file size, as a small pdf will work, but not a multi page pdf. The particular file I'm trying to get it to run through is a 12 page text pdf. I can get it to work if I sent the density low, for example (100, 100) works, but the quality is terrible.
The commented out lines were some other solutions I was trying to implement, but it keeps running for a long time (several minutes) without end (at least as far as my patience is concerned) with those enabled. One of those is to reduce quality, and the other to reduce image size. The pdfs always come out very large, much larger than necessary.
If I could reduce image size and/or quality before the file is written, that would be great. Or at least I need to be able to be able to produce an image in a quality that is decent enough without having memory issues. It doesn't seem like it should be having memory issues here as its not as if the file size is ginormous, although it probably still is bigger than desired for an image. The 12 page pdf when I could get it to render came in at around 6-7 megs.
I'm using 32-bit ImageMagick - I wonder if 64-bit would solve the issue, but there have been issues trying to get that version to run on a local environment - which is another issue entirely.
Anybody have any thoughts on anything else I can try?
Thanks
I have a problem when I'm working with image PDF files (PDF file with image only, no text) There are two PDF files img1, img2 and I want to combine two of them into one A4 page PDF file.
I have tried below code.
string Img1 = "C:/temp/image1.pdf";
string Img2 = "C:/temp/image2.pdf";
string MergedFile = "C:/temp/Combo.pdf";
//Create our PDF readers
PdfReader r1 = new PdfReader(Img1);
PdfReader r2 = new PdfReader(Img2);
//Our new page size, an A3 in landscape mode
iTextSharp.text.Rectangle NewPageSize = PageSize.A3.Rotate();
using (FileStream fs = new FileStream(MergedFile, FileMode.Create,
FileAccess.Write, FileShare.None))
{
//Create our document without margins
using (Document doc = new Document(NewPageSize, 0, 0, 0, 0))
{
using (PdfWriter w = PdfWriter.GetInstance(doc, fs))
{
doc.Open();
//Get our imported pages
PdfImportedPage imp1 = w.GetImportedPage(r1, 1);
PdfImportedPage imp2 = w.GetImportedPage(r2, 1);
//Add them to our merged document at specific X/Y coords
**w.DirectContent.AddTemplate(imp1, 0, 0);
w.DirectContent.AddTemplate(imp2, 0, -350);**
doc.Close();
}
}
}
r1.Close();
r2.Close();
So when i execute above code, because i have mentioned the y coord , it will combine pdf and two images will be on one page only.
BUt i don't want to do that
Here i am just giving example of two images,but in actual there are more than 20 images (converted into PDFs).
So depending on the image size, it should combine files. i can not give fix y coord for each n every file
Can anyone please help me to combine multiple PDF into single with no blank space..?
Structurally, here is what you want to do:
Allocate a new page of the "right" size
Merge the content streams of the pages
Merge the resources of the pages
Adjust all the annotations (if any)
The first step is easy, the rest, the second is easy, the third not so much (and will have the side effect of complicating step 2). I'll let you know ahead of time that I lied to you about the order.
Merging the content streams will be straight forward. What you will want to do is a four step process (I'll inject here that I know PDF very well, but iTextSharp not too well):
Insert a gsave operator (q)
Insert a transform operator (cm) to transform to the location where you want content to appear. In you case it will be 1 0 0 1 X Y cm
Copy the content streams from the current page
Insert a grestore operator (Q)
To merge the resources, you have to look at your newly created page's resources and for the current page do one of three things for each resource in each class of resource in a PDF page (XObject, Font, ColorSpace, ExtGState, Pattern, Shading, ProcSet - although for procset, you could set each procset to be the entire suite and do no harm):
If the resource exists in the newly created page, but under a different name, mark it as renamed.
If the resource does not exist in the newly created page and there is no resource with the same name, copy it in.
If the resource does not exist in the newly created page and there is a name conflict, rename the resource to a synthetic name not in the newly create page and copy it in.
Now to get back to my lie. In the resource merging, you will likely need a map built for the current page that maps old resource name to new resource name. When in the process of copying the content stream from one to the next, you will need to map all resource names referenced in the content stream to the new names built in the resource merge step.
To Adjust annotations, you will have to move them to their new location by adjusting the Rect property in each. You will also need to reset the /Parent property. For any of the text markup annotations, you will need to adjust the Quads.
Now, here is where the works will get gummed up in all of that. If a page is rotated, this will not work. If a page has a crop box, you will have to look at it and adjust the clipping region to simulate the crop. If the page is rotated and has Text annotations, this will need to attention to annotation flags to ensure that the aspect ratio is correct. If the document has link annotations on any of the pages with GoTo actions/destinations, you will need to adjust these.