A special that camera I am using returns me only images in bitmap format.
However, for the processes that I apply to that image (image processing), fails every time because of the image format.
And if the image is in ".jpeg" format everything works perfect.
My question is:
Is there any way to convert a bitmap to jpeg without saving to the
file system.
I saw there were few answers telling conversion by saving the image to the file system. That's not what I want. I need to convert and return those images.
I saw that C# had a class (below) but could not deploy it because I didn't know how to :
System.Drawing.ImageFormatConverter
Thanks in advance for your time, and valuable helps.
You probably want to look at imageresizing.net.
FreeImage could also be an alternative, though Ive found it a bit buggy at times.
Related
I'm working on extracting images that were saved in an access database. Some were saved as Bitmap Image, some where saved as Microsoft Photo Editor (which shows up as MSPhotoEd.3). For each record containing bitmap images I'm obtaining the hexidecimal data that is saved and using the file signatures to obtain the image data and converting to binary. This works perfectly and as expected.
I'm currently attempting to do the same thing for the Microsoft Photo Editor images, however I'm having a difficult time finding documentation as to how this file format is structured. I'm going through the hex and I see signatures that would correlate to a jpeg file, however there are several of them (3 markers FFD8FF) and they do not coincide with eachother (22 trailers FFD9). It could be that this format is completely different and those just happen to show up...I'm not sure.
Has anyone attempted to do this before? Is it possible to extract a jpeg image from this file format (Microsoft Photo Editor)? If not does anyone know what the best way would be to go about converting this file format to any other usable image format programmatically?
I'm writing a service for a project that's going to handle our image processing. One such process is supposed to strip all metadata from the byte[] provided and return the same image as a byte[].
The method I'm currently working on involves always converting the image to a Bitmap, then converting it back to the original format and returning the data from a MemoryStream.
I haven't been able to test it yet but something tells me I'm going to experience some quality loss.
How can I remove all metadata from any image with a common format?
(bmp, gif, png, jpg, icon, tiff)
Not sure how I can narrow that down any further. Would be nice if I got some feedback regarding the downvotes.
For the lossless formats (except JPEG), your idea of loading it as a bitmap and re-saving is fine. Not sure if .NET natively supports TIFFs (I doubt it does).
For JPEGs, as you suggested there may be quality loss if you're re-compressing the file after decompressing it. For that, you might try the ExifLibrary and see if that has anything. If not, there are command line tools (like ImageMagick) that can strip metadata. (If you use ImageMagick, you're all set, since it supports all of your required formats. The command you want is convert -strip.)
For TIFFs, .NET has built-in TiffBitmapDecoder and ...Encoder classes you might be able to use; see here.
In short, using an external tool like ImageMagick is definitely the easiest solution. If you can't use an external tool, you're almost certainly going to need to special-case the formats that .NET doesn't support natively (and the lossy JPEG).
EDIT: I just read that ImageMagick doesn't do lossless stripping with JPEGs, sorry. I guess using the library I linked above, or some other JPEG library, is the best I can think of.
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))
My C# application receives image files from KOFAX VRS TWAIN driver in TWSX_FILE mode, but neither my own .NET based application nor Windows default image viewer can open these files. However, Adobe Photoshop can open them without any problem.
I tried FreeImage library and although it detects their dimensions correctly it renders black images.
It seems that KOFAX has some kind of its own bitmap format which its header is different from normal bmp files:
http://www.fileformat.info/mirror/egff/ch03_03.htm
I have uploaded one of these files here:
http://www.box.net/shared/aby42aagz4
I wanted to know how can I open these images in my applications, anybody knows any lightweight open source/free library or C++/C# code snippet, supporting this image format?
You've basically answered your own question: The file is neither a Windows bitmap file nor is it in the documented Kofax Raster Format.
As you pointed out, the first two bytes are 'BM', which would indicate the file is purporting to be a Windows bitmap. However, if that were truly the case the next four bytes would contain the file size. In your sample file, the next four bytes contain a value much bigger than the actual file size so it can't be correctly interpreted as a Windows bitmap file.
As the fileformat.info site you linked to states, if the file was truly in Kofax Raster Format, it would start with the bytes '68464B2Eh'. Thus, your file isn't in Kofax Raster Format either. In fact, I tried opening it with Kofax's VCDemo software and got the following error: "Error 20204 - Internal invalid state"
Thus, Kofax's own software thinks the file is corrupt.
The fact that Photoshop can open it and display something doesn't necessarily mean it's a valid image file format. Image processing software packages will often simply try to guess at interpreting the raw bytes of the file. Sometimes they get lucky, sometimes not.
Trying to find something that can read the files assumes that the file is in a standard format, which it isn't. Thus, I wouldn't search for something that could read the file but instead search for why the VRS/TWAIN configuration you are using is producing a non-standard format.
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.