I've been using MigraDoc to generate PDFs and I've got the layout of everything working great except for adding in images. for the part of the program we're generating these PDFs for we're using a program that only saves their information as XML and from there am able to convert the XML into System.Drawing.Image objects. The problem I'm running into is somehow getting the System.Drawing.Image objects now into my PDFs.
MigraDoc was designed to work with filenames. So one option is saving the stream to a temporary file and then use the filename.
Or modify the MigraDoc source code to work with image objects - such a patch can be found on the PDFsharp forum.
BTW: The downvote is not from me. Maybe someone thinks that very little effort was used to post the question here.
Update (January 16, 2016): With version 1.50 (currently available as beta version only, but it is pretty stable) you can pass images in the filename: the filename will contain the image bytes using BASE64 encoding.
It's a bit of a hack, but should work for all scenarios.
Sample code here:
http://pdfsharp.net/wiki/MigraDoc_FilelessImages.ashx
So MigraDoc still uses filenames only, but it is no longer necessary to save images in temporary files.
I don't know where this solution started working, but I usually solve this problem with simple method to convert stream into virtual file path.
internal static string LoadImageFromBytes(byte[] cData)
{
return $"base64:{Convert.ToBase64String(cData)}";
}
And then use it in AddImage() method:
row[0].AddImage(LoadImageFromBytes(byteArray))
Related
Does anyone know a way to render or export a pdf with either the text or the images stripped out?
I noticed a way that uses GhostScript:
https://stackoverflow.com/a/38010769/4437032
Unfortunately it would require me to get a commercial licence (since I intend to distribute).
The renderer I have been using up until now has been Pdfium, but that library has no capability to do this (without modifying the native code).
I also looked into PDFSharp, but it seems to be more for appending things to PDFs rather than removing things.
I cannot expect any kind of pdf editing software to be installed on machines that run my program, so ideally I'm looking for some free library.
Does anyone know of any solutions?
I ended up using the free version of Spire.Pdf to accomplish my goal, using it to create pdfs with either text or images. The free version limits you to a max of 10 pages in processed pdfs, but that is acceptable for me.
No images: delete all the images using Spire.Pdf
No text: extract all the images using Spire.Pdf, draw them onto a blank pdf.
then display the modified pdfs.
I am using MigraDoc, and would like to insert an image in a document. The simplest way to do this, is to provide a path for the image file (rather than having it in the resources). So what I would like to do is, to include an image as a file, alongside the other files in the build. Then MigraDoc can use the image based on relative path.
But I have no clue how to do this or if it is even possible. So can I make my project include an image file, outside the resources.
P.S. I know that there is a work around, where you include the image in the resources, save it in a temporary folder before MigraDoc has to use it. It just seems like a simpler design, if the image is always available.
P.P.S. There is a work around, to make MigraDoc use images from the project resources (see accepted answer).
As shown on the MigraDoc site you can use images you have as a byte[] to create PDF files. This can easily be used with images from resources (as shown on the site).
You just convert the image resource to a special string and pass that string where MigraDoc expects a filename.
static string MigraDocFilenameFromByteArray(byte[] image)
{
return "base64:" +
Convert.ToBase64String(image);
}
Link to official MigraDoc site:
http://www.pdfsharp.net/wiki/MigraDoc_FilelessImages.ashx
And MigraDoc can also use images that are stored in the program folder with your assemblies. You can use the Assembly class to find out where your assembly is stored and search that folder for images that should be there. This has nothing to do with MigraDoc, just some basic .NET features.
I'm working in C# with Spire.PDF. Specifically, my goal is to load binary PDF data from a database into a Spire.Pdf.PdfDocument object.
According to this documentation, I should be able to use the LoadFromStream() method or some unspecified method that takes a byte array (see bottom of page at link where there is a link but only to the general documentation). However, this method seems absent from the current NuGet package.
So, in summary, how can I make a Spire.Pdf.PdfDocument object using a byte array of data? Thanks in advance.
Please comment if you know a better .NET library for converting PDFs to and from images.
With all the smarts of actually loading images being done by the .net framework, seems like I shouldn't have to repeat it all in my code by checking for magic numbers, or using a hack like this:
Private Function IsImage(FileName as String) As Boolean
Try
Using img As New Bitmap(FileName)
End Using
Catch ex as System.ArgumentException
Return False
End Try
Return True
End Function
Am I missing something obvious, like System.Drawing.IsImage(stream)?
You will need to open up the file and read the relevant headers for the file types you want to support, as mentioned here:
determine if file is an image
I don't think there is anything already in the .NET framework that can do this for you, other than loading it into an image and querying the image format:
Find image format using Bitmap object in C#
An alternative theory (no actual facts to back this one up): perhaps the file in Windows holds meta-data that flags it as an image - in the same manner than the properties dialog seems to show artist information for audio files. This could be a cute way to avoid opening the file.
Edit by FastAl Jun 2020. More useful links:
Using .NET, how can you find the mime type of a file based on the file signature not the extension
Not what I asked for, but here are the magic #s:
https://en.wikipedia.org/wiki/List_of_file_signatures
https://www.garykessler.net/library/file_sigs.html
I have a raw pixel data in a byte[] from a DICOM image.
Now I would like to convert this byte[] to an Image object.
I tried:
Image img = Image.FromStream(new MemoryStream(byteArray));
but this is not working for me. What else should I be using ?
One thing to be aware of is that a dicom "image" is not necessarily just image data. The dicom file format contains much more than raw image data. This may be where you're getting hung up. Consider checking out the dicom file standard which you should be able to find linked on the wikipedia article for dicom. This should help you figure out how to parse out the information you're actually interested in.
You have to do the following
Identify the PIXEL DATA tag from the file. You may use FileStream to read byte by byte.
Read the pixel data
Convert it to RGB
Create a BitMap object from the RGB
Use Graphics class to draw the BitMap on a panel.
The pixel data usually (if not always) ends up at the end of the DICOM data. If you can figure out width, height, stride and color depth, it should be doable to skip to the (7FE0,0010) data element value and just grab the succeeding bytes. This is the trick that most normal image viewers use when they show DICOM images.
There is a C# library called EvilDicom (http://rexcardan.com/evildicom/) that can be used to pull the image out of a DICOM file. It has a tutorial on how to do it on the website.
You should use GDCM.
Grassroots DiCoM is a C++ library for DICOM medical files. It is automatically wrapped to python/C#/Java (using swig). It supports RAW, JPEG 8/12/16bits (lossy/lossless), JPEG 2000, JPEG-LS, RLE and deflated (zlib).
It is portable and is known to run on most system (Win32, linux, MacOSX).
http://gdcm.sourceforge.net/wiki/index.php/GDCM_Release_2.4
See for example:
http://gdcm.sourceforge.net/html/DecompressImage_8cs-example.html
Are you working with a pure standard DICOM File? I've been maintainning a DICOM parser for over a two years and I came across some realy strange DICOM files that didn't completely fulfill the standard (companies implementing their "own" twisted standard DICOM files) . flush you byte array into a file and test whether your image viewer(irfanview, picassa or whatever) can show it. If your code is working with a normal JPEG stream then from my experience , 99.9999% chance that this simply because the file voilate the standard in some strange way ( and believe me , medical companies does that a lot)
Also note that DICOM standard support several variants of the JPEG standard . could be that the Bitmap class doesn't support the data you get from the DICOM file. Can you please write down the transfer syntax?
You are welcome to send me the file (if it's not big) yossi1981#gmail.com , I can check it out , There was a time I've been hex-editing DICOM file for a half a year.
DICOM is a ridiculous specification and I sincerely hope it gets overhauled in the near future. That said Offis has a software suite "DCMTK" which is fairly good at converting dicoms with the various popular encodings. Just trying to skip ahead in the file x-bytes will probably be fine for a single file but if you have a volume or several volumes a more robust strategy is in order. I used DCMTK's conversion code and just grabbed the image bits before they went into a pnm. The file you'll be looking for in DCMTK is dcm2pnm or possibly dcmj2pnm depending on the encoding scheme.
I had a problem with the scale window that I fixed with one of the runtime flags. DCMTK is open source and comes with fairly simple build instructions.