I have simple database in Access .mdb file, but I don't know how to deal with: "parameter not valid" exception when Im creating Image from stream.
I'v read that I need to strip 78 bytes offset (from here) but I still get a "parameter not valid" error
when I call FromStream, even after stripping off the first 78 bytes.
This doesn't work for me:
byte[] abytPic = (byte[])dt.Rows[0]["Photo"]; byte arrary with image
if ((abytPic[0] == 21) && (abytPic[1] == 28)) //It's true
{
byte[] abytStripped = new byte[abytPic.Length - 78];
System.Buffer.BlockCopy(abytPic, 78, abytStripped, 0, abytPic.Length - 78);
msPic = new emoryStream(abytStripped);
}
If you are reading the data directly from MS Access, you do not need to strip any header information.
Assuming the image is stored as a BLOB, which is the most common, here is code to read in the array of bytes from the database and store as an image file (sorry, VB instead of C#):
Dim varBytes() As Byte
Using cn As New OleDbConnection(myConnectionString)
cn.Open()
sqlText = "SELECT [myColumn] " _
& "FROM [myTable] " _
& "WHERE ([mySearchCriteria] = '" & mySearchTerm & "')"
Using cm As New OleDbCommand(sqlText, cn)
Dim rdr As OleDbDataReader
rdr = cm.ExecuteReader
rdr.Read()
varBytes = rdr.GetValue(0)
End Using
End Using
My.Computer.FileSystem.WriteAllBytes(myPath & "\myFile.emf", varBytes, True)
This example that I had laying around is one where I knew the files in the database were .emf images. If you know the extension, you can put it on the file name. If you don't, you can leave it blank and then open the resulting with an image viewer; it should start. If you need to find the extension or file type, once it is saved as a file, you can open it with any hex editor and the file type will be available from the header information.
Your question is a little bit unclear, so I'm not sure the above code is exactly what you want, but it should get you a lot closer.
EDIT:
This is the VB code that takes the array of bytes, loads it into a MemoryStream object, and then creates an Image object from the Stream. This bit of code worked just fine, and displayed the image in a picturebox on my form.
Dim img As Image
Dim str As New MemoryStream(varBytes)
img = Image.FromStream(str)
PictureBox1.Image = img
If the C# equivalent of this is not working for you, then the problem is likely in how the image is stored in the MS Access database.
EDIT:
If the image in your database is stored as a 'Package' and not a 'Long binary data', then you will need to strip the header information that MS Access adds. I've been playing with the 'Package' type of image storage with a simple .jpg file. The header in this case is much longer than 78 bytes. In this instance, it's actually 234 bytes, and MS Access also added some information to the end of the original file; about 292 bytes in this case.
It looks like your original approach was correct, you will just need to determine how many bytes to strip off the front and rear of the Byte array for your situation.
I determined it for my file by comparing the original image file, and the file exported from the database, (not to a Stream object, see my first code) in a hex editor. Once I figured out how much information (header and footer) was added by MS Access, I then knew how many bytes needed to be stripped.
EDIT:
The size of the header added by MS Access when the image is stored as 'Package' varies depending on the file type, and the original location (full path information) of the image when it was dumped into the MS Access database. So, even for the same file type, you may have a different number of bytes to strip from the header for each file.
This makes it a lot more difficult, because then you will have to scan the byte array until you find the normal start-of-file information for that file type, and then strip everything before it.
All this headache is one of the reasons that it is better to store images as BLOBs 'Long binary data' in a database. Retrieval is much easier. I don't know if you have the option to do this, but if so, it would be a good idea.
I do not believe that your problem is with the database. "Parameter not valid" exceptions when dealing with imaging can be a total pain as I have dealt with them before. They're not very clear on what the problem is.
How exactly was the image placed into the database? There could be a problem with writing the image into the database before you've even attempted to pull it. Also, what file type is the image?
EDIT Here is some sample code that I've used before to get an image from a byte array.
//takes an array of bytes and converts them to an image.
private Image getImageFromBytes(byte[] myByteArray)
{
System.IO.MemoryStream newImageStream = new System.IO.MemoryStream(myByteArray, 0, myByteArray.Length);
return Image.FromStream(newImageStream, true);
}
Related
I got a MySql backup file containing a column like:
CREATE TABLE `person` (
`id` int(11) NOT NULL AUTO_INCREMENT,
`profilepicture` blob,
)
The content of this row profilepicture is encoded in the backup file to some kind of dump, starting (in a text editor) like this:
INSERT INTO `tbox_account_transaction` VALUES (8,'?\?\?0JFIF\0\0\0\0\0\0[...]');
How can I decode this from the .sql backup file in c#? It is not Base64, but I do not recognize what else it might be. I don't want to restore the backup.sql file to MySql but instead decode the blob from the backup file.
The bytes you are seeing are almost certainly the initial bytes of a JPEG image. The readable string "JFIF" starting at the fifth byte is the clue (see https://en.wikipedia.org/wiki/JPEG_File_Interchange_Format).
Many of the other binary bytes are null or else non-printable characters. All the weird \? or \0 sequences are the client's best effort at representing these bytes on your text display.
The easiest way to access this data is to restore the dump file to a MySQL instance (even a local one running on a laptop), and then use SQL in your C# code to access the binary contents of the profilepicture blob.
Either save the data from one blob to a .jpg file as #Tommaso Belluzzo suggests, or else just display it directly, if you can. I'm not a C# programmer, but it seems there's a Bitmap class for this (see https://msdn.microsoft.com/en-us/library/8tda2c3c(v=vs.85).aspx).
It's outside the scope of a Stack Overflow answer to give a tutorial on how to write SQL in a C# application. There are plenty of resources available for that.
That looks like a jpg file header. Try the following (blob is a String typed variable containing the profilepicture):
using (MemoryStream stream = new MemoryStream(buffer))
{
Image image = Image.FromStream(stream, true, true);
image.Save("C:\\Test.jpg", ImageFormat.Jpeg);
}
I've got a c# application which saves and displays records, When saving a record with an image using the picture box it seems as though the image has saved just fine but in the database all the images seem to have the same tag
[BLOB - 13B]
when saving the exact same image into the database manually using the dbms the image tag will read
[BLOB - 2.4KB]
with this tag I can use my image display method and it will be fine
The image is being converted or something when being saved but I cant seem to understand what is the problem.
here is the code for selecting and saving the image
MemoryStream ms = new MemoryStream();
pictureBox.Image.Save(ms, pictureBox.Image.RawFormat);
byte[] img = ms.ToArray();
because of the way this code changes the image, when retrieving it, I receive an error which says "parameter is invalid"
using c# and a mysqldatabase, although the database type is irrelevant.
Anyone understand what is going wrong?
It sounds like you're saving a byte array of your image to your database and need to know how to convert that byte array back into an image so that it can be displayed. You can do that with a function like this:
public Image ConvertByteArrayToImage(byte[] byteArray)
{
MemoryStream ms = new MemoryStream(byteArray, 0, byteArray.Length);
ms.Write(byteArray, 0, byteArray.Length);
Image image = Image.FromStream(ms, true);
return image;
}
UPDATE: After reading it over again. I don't think I answered the actual question you were asking. It sounds like your not converting your image into a byte array. I would try taking the image from your picturebox and putting it into an Image object. Then converting that Image object into a byte array. Rather than saving picturebox.Image.RawFormat
For any future readers.
I figured out my own problem after some research, turns out that when I was concatenating the SQL string and placing the byte array into it, the byte array would be changed to follow the string parameters. Hence the blob in the database would say [Blob 13B] only rather than the 2.7KB it should have been
To avoid this, you have to use a "parameterized" SQL query and not a standard concatenated one.
see Why my BLOB field is still 13B - what I am doing wrong?
and SQL Insert Query Using C#
I'm trying to convert several byte arrays (stored in SQL Server 2008 R2 as varbinary(8000)) into images so I can attach them to a PDF file (an example of the data is below). I keep getting "Parameter is not valid." when creating the Image from the MemoryStream. Any help on this?
MemoryStream memoryStream = new MemoryStream(byteArray);
Image image = Image.FromStream(memoryStream);
Bitmap bitmap = new Bitmap(image);
0x0A020101000000005E006500FA00FA0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010C00010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000C1C0C7000FC2FFC1FE80C70007C2FFC1FE1FC7FFC1F03FC1FFC1FE3FC7FFC1F807C1FFC1FE3FC8FFC1F3C1FFC1FE3FC8FFC1FEC1FFC1FE3FC8FFC1FE7FC1FE3FC9FFBFC1FE3FC9FFC1DFC1FE3FC9FFC1CFC1FE3FC9FFC1F3C1FE3FC9FFC1FBC1FE3FC9FFC1F9C1FE3FC9FFC1F9C1FE3FC9FFC1FCC1FE3FC9FFC1FE7E3FC9FFC1FE7E3FCAFF7E3FC2FFC1FCC20007C4FF3E3FC2FFC1F8C300C4FF3E3FC2FFC1F1C2FFC1FC7FC3FF3E3FC2FFC1F1C2FFC1FC3FC3FF3E3FC2FFC1F1C3FF9FC3FF3E3FC2FFC1F1C3FFC1CFC3FF3E3FC2FFC1F1C3FFC1E7C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C2FFC1FE7E3FC2FFC1F1C3FFC1E7C2FFC1FE7E3FC2FFC1F1C3FFC1C7C2FFC1FCC1FE3FC2FFC1F1C3FFC1C7C2FFC1F9C1FE3FC2FFC1F1C3FFC1DFC2FFC1F9C1FE3FC2FFC1F1C3FFBFC2FFC1F9C1FE3FC2FFC1F1C2FFC1FC3FC2FFC1F3C1FE3FC2FFC1F0C2FFC1F8C3FFC1E7C1FE3FC2FFC1FEC2000FC3FFC1CFC1FE3FC3FFC2000FC3FF9FC1FE3FC9FF3FC1FE3FC8FFC1FE7FC1FE3FC8FFC1F0C1FFC1FE3FC8FFC1E7C1FFC1FE3FC8FFC1CFC1FFC1FE3FC8FF8FC1FFC1FE3FC8FFC1E0C1FFC1FE3FC8FFC1F8C1FFC1FE3FC8FFC1FC1FC1FE3FC9FF8FC1FE3FC9FFC1E7C1FE3FC9FFC1F0C1FE3FC9FFC1FE7E3FCAFF7E3FC2FFC1FCC300C4FF3E3FC2FFC1F8C3001FC3FF3E3FC2FFC1F1C3FF8FC3FF9E3FC2FFC1F1C3FF87C3FFC1CE3FC2FFC1F1C3FFC1F3C3FFC1CE3FC2FFC1F1C3FFC1F9C3FFC1EE3FC2FFC1F1C3FFC1FCC3FFC1E43FC2FFC1F1C3FFC1FE7FC2FFC1E43FC2FFC1F1C4FF3FC2FFC1E43FC2FFC1F1C4FF1FC2FFC1F03FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C3FFC1FE7FC2FFC1F83FC2FFC1F1C3FFC1FEC3FFC1F83FC2FFC1F1C3FFC1F9C3FFC1F83FC2FFC1F1C3FFC1F3C3FFC1F83FC2FFC1F1C3FFC1F7C3FFC1F83FC2FFC1F1C2FFC1FE0FC3FFC1F83FC2FFC1F0C3003FC3FFC1F83FC2FFC1F8C20001C4FFC1F83FC2FFC1FCC20003C4FFC1FC3FCAFFC1E43FCAFFC1E43FCAFFC1E43FCAFFC1EE3FCAFFC1EE3FCAFFC1CE3FCAFF3E3FCAFF7E3FC9FFC1FE7E3FC9FFC1FE7E3FC9FFC1FCC1FE3FC9FFC1F1C1FE3FC9FFC1C3C1FE3FC9FFC1DFC1FE3FC9FF9FC1FE3FC8FFC1E07FC1FE3FC8FFC1C1C1FFC1FE1FC7FF001FC1FFC1FEC9003FC1FFC1FE80C700C3FFC1FEC1C0C700C3FFC1FE
It's a
% file output
output: PCX ver. 2.8 image data, with palette
under linux I just transformed your hex stream from plain text to a binary file called output
echo
"0A020101000000005E006500FA00FA0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000010C00010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000C1C0C7000FC2FFC1FE80C70007C2FFC1FE1FC7FFC1F03FC1FFC1FE3FC7FFC1F807C1FFC1FE3FC8FFC1F3C1FFC1FE3FC8FFC1FEC1FFC1FE3FC8FFC1FE7FC1FE3FC9FFBFC1FE3FC9FFC1DFC1FE3FC9FFC1CFC1FE3FC9FFC1F3C1FE3FC9FFC1FBC1FE3FC9FFC1F9C1FE3FC9FFC1F9C1FE3FC9FFC1FCC1FE3FC9FFC1FE7E3FC9FFC1FE7E3FCAFF7E3FC2FFC1FCC20007C4FF3E3FC2FFC1F8C300C4FF3E3FC2FFC1F1C2FFC1FC7FC3FF3E3FC2FFC1F1C2FFC1FC3FC3FF3E3FC2FFC1F1C3FF9FC3FF3E3FC2FFC1F1C3FFC1CFC3FF3E3FC2FFC1F1C3FFC1E7C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C3FF3E3FC2FFC1F1C3FFC1F3C2FFC1FE7E3FC2FFC1F1C3FFC1E7C2FFC1FE7E3FC2FFC1F1C3FFC1C7C2FFC1FCC1FE3FC2FFC1F1C3FFC1C7C2FFC1F9C1FE3FC2FFC1F1C3FFC1DFC2FFC1F9C1FE3FC2FFC1F1C3FFBFC2FFC1F9C1FE3FC2FFC1F1C2FFC1FC3FC2FFC1F3C1FE3FC2FFC1F0C2FFC1F8C3FFC1E7C1FE3FC2FFC1FEC2000FC3FFC1CFC1FE3FC3FFC2000FC3FF9FC1FE3FC9FF3FC1FE3FC8FFC1FE7FC1FE3FC8FFC1F0C1FFC1FE3FC8FFC1E7C1FFC1FE3FC8FFC1CFC1FFC1FE3FC8FF8FC1FFC1FE3FC8FFC1E0C1FFC1FE3FC8FFC1F8C1FFC1FE3FC8FFC1FC1FC1FE3FC9FF8FC1FE3FC9FFC1E7C1FE3FC9FFC1F0C1FE3FC9FFC1FE7E3FCAFF7E3FC2FFC1FCC300C4FF3E3FC2FFC1F8C3001FC3FF3E3FC2FFC1F1C3FF8FC3FF9E3FC2FFC1F1C3FF87C3FFC1CE3FC2FFC1F1C3FFC1F3C3FFC1CE3FC2FFC1F1C3FFC1F9C3FFC1EE3FC2FFC1F1C3FFC1FCC3FFC1E43FC2FFC1F1C3FFC1FE7FC2FFC1E43FC2FFC1F1C4FF3FC2FFC1E43FC2FFC1F1C4FF1FC2FFC1F03FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C4FF1FC2FFC1F83FC2FFC1F1C3FFC1FE7FC2FFC1F83FC2FFC1F1C3FFC1FEC3FFC1F83FC2FFC1F1C3FFC1F9C3FFC1F83FC2FFC1F1C3FFC1F3C3FFC1F83FC2FFC1F1C3FFC1F7C3FFC1F83FC2FFC1F1C2FFC1FE0FC3FFC1F83FC2FFC1F0C3003FC3FFC1F83FC2FFC1F8C20001C4FFC1F83FC2FFC1FCC20003C4FFC1FC3FCAFFC1E43FCAFFC1E43FCAFFC1E43FCAFFC1EE3FCAFFC1EE3FCAFFC1CE3FCAFF3E3FCAFF7E3FC9FFC1FE7E3FC9FFC1FE7E3FC9FFC1FCC1FE3FC9FFC1F1C1FE3FC9FFC1C3C1FE3FC9FFC1DFC1FE3FC9FF9FC1FE3FC8FFC1E07FC1FE3FC8FFC1C1C1FFC1FE1FC7FF001FC1FFC1FEC9003FC1FFC1FE80C700C3FFC1FEC1C0C700C3FFC1FE"
| xxd -p -r >output
and then the easy part with file output to get the name of the file format from the utility file.
First, make sure you know the encoding, as the Image.FromStream method knows only a limited number of formats.
Make sure that the Position of your MemoryStream is set properly to 0, and not to the end - otherwise, any reads will begin at the end appear to be empty, instead of starting at the beginning.
Also, note that
This constructor does not expose the underlying stream. GetBuffer throws UnauthorizedAccessException.1
Thus, this could be caused by some of the way Bitmap is handling the underlying stream. IF need be, try making an empty memorystream, copying the byte into it, and then resetting the position
MemoryStream memoryStream = new MemoryStream();
foreach(var b in byteArray) memoryStream.WriteByte(b);
memoryStream.Position = 0;
Image image = Image.FromStream(memoryStream);
The byte array you gave is 1117 bytes long. That's not evenly divisible by 4 or 3, so I'm pretty certain that the image is not raw bytes and is actually encoded in an image format of some sort.
The Image.FromStream() method can't decode an encoded image without knowing the format, and the byte array you gave doesn't specify what that format is. Therefore the parameter you gave is invalid. If you know the format of the image you could attempt to insert a header into the byte array before the rest of the image, and see if that helps. It's curious you have the image but not its header, although it doesn't appear to be a base-64 string either.
Without knowing the image format it could be difficult to convert these byte arrays into images. Is there any way you could find out what they are? How is the image data retrieved to be stored?
Wee bit of background to set the scene : we've told a client he can provide us with images of any type and we'll put them on his reports. I've just had a quick run through of doing this and found that the reports (and other things between me and them) are all designed to only use SVGs.
I thought I'd struck gold when I found online that you can convert an image from a jpg or PNG into an SVG using free tools but alas I've not yet succeeded in getting an SVG stored as bytes in the DB in a format that allows me to use it again after reading it back out.
Here's a quick timeline of what followed leading up to my problem.
I use an online tool to generate an SVG from a PNG (e.g., MobileFish)
I can open and view it in Firefox and it looks ok
I ultimately need the SVG to be stored as bytes in the DB, from where the report will pull it via a webpage that serves it up as SVG. So I write it as bytes into a SQL data script. The code I use to write these bytes is included below.
I visit said webpage and I get an error that there is an "XML parsing error on Line 1 Column 1" and it shows some of my bytes. They begin "3C73"
I revisit the DB and compare the bytes I've just written there with some pre-existing (and working ones). While my new ones begin "3C73", the others begin "0xFFFE".
I think I've probably just pointed out something really fundamental but it hasn't clicked.
Can someone tell me what I've done that means my bytes aren't stored in the correct encoding/format?
When I open my new SVG in Notepad++ I can see the content includes the following which could be relevant :
<image width="900" height="401" xLink:href="data:image/png;base64,
(base 64 encoded data follows for 600+ lines)
Here's the brains of the code that turns my SVG into the bytes to be stored in DB :
var bytes = File.ReadAllBytes(file);
using (var fs = new StreamWriter(file + ".txt"))
{
foreach (var item in bytes)
{
fs.Write(String.Format("{0:X2}",item));
}
}
Any help appreciated.
Cheers
Two things:
SVGs are vector images, not bitmap files. All that online tool is doing is taking a JPEG and creating a SVG file with a JPEG embedded in it. You aren't really getting the benefit of a true SVG image. If you realise and understand that, then no worries.
SVG files are just text. In theory there is no reason you can't just store them as strings in your db. As long as the column is big enough. However normally if you are storing unstructured files in a db, the preferred column type to use is a "Blob".
http://technet.microsoft.com/en-us/library/bb895234.aspx
Converting your SVG file to hex is just making things slower and doubling the size of your files. Also when you convert back, you have to be very careful about the string encoding you are using. Which, in fact, sounds like the problem you are having.
I am suspecting you are doing it incorrectly. SVG is simply and XML based vector image format. I guess your application might be using SVG image element and you need to convert your png image to base64 encoded string .
I have some C# code that converts an image to base64 string. The code is :
MemoryStream ms = new MemoryStream();
Image img = Image.FromFile(filename);
img.Save(ms, System.Drawing.Imaging.ImageFormat.Jpeg);
string s = Convert.ToBase64String(ms.GetBuffer());
I am trying to implement it with JAVA. my java code is :
BufferedImage img = null;
img = ImageIO.read(new File(filename));
byte[] bytes = ((DataBufferByte)img.getData().getDataBuffer()).getData();
String js = Base64.encodeBase64String(bytes);
this two piece of code should return the same string for the same image file. But they are returning different strings. I am unable to figure out why. Can anyone shed some light on it?
this two piece of code should return the same string for the same image file
No, they really shouldn't.
The C# code is returning the base64 representation of a JPEG-encoded version of the image data - and potentially some 0s at the end, as you're using GetBuffer instead of ToArray. (You want ToArray here.)
The Java code is returning the base64 representation of the raw raster data, according to its SampleModel. I'd expect this to be significantly larger than the string returned by the C# code.
Even if both pieces of code encoded the image with the same format, that doesn't mean they'll come up with the exact same data - it will depend on the encoding.
Importantly, if you just want "the contents of the file in base64" then you don't need to go via an Image at all. For example, in C# you could use:
string base64 = Convert.ToBase64String(File.ReadAllBytes(filename));
The fact that it's an image is irrelevant in that respect - the file is just a collection of bytes, and you can base64-encode that without understanding the meaning of those bytes at all.