Hello, I am using READBIN() to import raw images into mathcad. Due to a very strange file format, I have to run READBIN 4 times (must get data of types int16, float, uint16, and uint32). Because of this, it's kind of a pain to use the file input component - you have to do it 4 times! Right now I'm typing the file directory/filename into a variable which is then passed to 4 READBIN functions. Instead of typing in the filename every time (is a pain when files are stored on the desktop!) is there a way to get one of those "browse" dialog boxes into the mathcad sheet? Then I select the file in that and the name is written to a variable as a string? If not, any other suggestions on ways to make this easier? This worksheet will eventually be used by people with limited computer experience, so I need to make it as easy-to-use as possible.
ahhh, thank you very much. The first worksheet is exactly what I'm looking for! I have very limited coding experience, and none at all with VB. I figured there was a way, but I had no idea how to go about it! Thanks again!
Nitpicking - when you push "cancel" instead of choosing a file in the selection dialog box, the script output is "null". Passing this to the READBIN() function crashes Mathcad without fail, hehe. If you change that output to "no file" or something similar, this problem disappears.
Somebody at PTC wrote that component, not me, so feel free to nitpick all you wish 🙂
I could also do some nitpicking on that one. The starting path and the filter string shold be input parameters, not hard coded. Then it would also need some error trapping in case the initial path did not exist. Error trapping for invalid filter stings would be a good idea too.
Someday, when I have a lot more time than I have right now, maybe I'll improve it. Or you could post your improved version 😉
I am using READBIN() to import raw images into mathcad. Due to a very strange file format, I have to run READBIN 4 times (must get data of types int16, float, uint16, and uint32). Because of this, it's kind of a pain to use the file input component - you have to do it 4 times!" ________________
"very strange file format" What then is the file format ? Does windows puts the image on the screen ? If so, that would ease the task !
If a software reads that image file format, then view on the screen and go form there because the Windows clipboard is a file format converter, it converts in bitmap matrix.
The problem is, I'm doing lens quality (mtf) testing with these images. The camera output is a 12/14-bit (depending on which camera I'm using) raw image, which is broken up into 4 parts - response, offset, Bad pixel map, and gain. Each part is in a different number format (the ones listed in my first post). There is a program I could use to get the images in 8-bit .bmp format, but I need the 12-bit numbers to make an accurate measurement.
Anyways, the file selection tool linked above works great, despite the flaws rijackson pointed out. I think I'll take a stab at fixing those, and then post my own offering.
"The camera output is a 12/14-bit (depending on which camera I'm using) raw image, which is broken up into 4 parts - response, offset, Bad pixel map, and gain". _____________________
Mathcad reads many conventional image format: gif, tif, jpeg, bmp ... What you want is Mathcad reading bits and bytes from the sensors and pack them into an image format. If you are analyzing components you might need some NI input cards and convert to a Mathcad NI compatibility number format. Most probably I'm lost ! My previous suggestion is still valid: if you read an image of a Mathcad incompatible format, then capturing this image via the Windows clipboard operation will enable to read it back in Mathcad. What I'm saying here is like capturing a web image, as long as it appears on the Windows screen, then the conversion is done for a bmp format.
You don't really need to read the data four times just because of the formats. You can read it just once and do the conversions in Mathcad. Full generality would read the file as bytes, and then convert one or more consecutive bytes to any required format. With the formats you've listed you could read as uint16 or int16 and start from there. Converting from uint16 to int16 just requires subtracting 216 from any number ≥ 215. Converting from int16 to uint16 just requires adding 216 to any negative number. int32 can be constructed from a pair of 16 bit numbers. Multiply the first, taken as int16, by 216 and add the second, taken as uint16. Interchange the first and second if the data is stored in little endian format rather than big endian format. Float is a bit more complicated (and I'd have to check on the details of the format) but is not difficult.
Here's a sheet with some conversion utilities for different number formats. It should allow a file to be read just once, as bytes, and pieces of it converted to various numeric formats as needed. There are also conversions starting with uint16 format.
I'm not having any problems inputting the files...
There are 8-bit numbers mixed in at certain spots, meaning the data would get mixed up if I imported in a 16-bit format. I guess I could import as uint8 or int8 and go from there, but it works right now and doesn't take all that long.
Well, your original post did not specify any eight bit formats, only formats in multiples of sixteen bits. But that doesn't really matter, as the conversion sheet provides conversions from byte to all other formats. So the file can be read once in byte format, and all other formats calculated from the bytes.
I agree that time is not an issue (unless the files were to be really huge). It's mostly a matter of the level of inconvenience of having to read the file multiple times. And a rebuttal of the claim that the multiple formats required such multiple reads. While multiple reads in different formats is a perfectly valid method of handling such mixed format files, it is by no means the only method.
Colin, You should now be able to combine the various parts together.
In similar camera testing environments I have found that the 'browse for filename' portion should be a single stand alone button, (rather than be inside a function) because you want it to happen the once, under user control, and occur just the once in the sheet.
This compares with the directory listing components (see Richard's posts) which are often better as functions, as usually you want to automatically go through all the files in a directory.
The four READBIN actions can all be combined into one function (programme) - just pass in the file name as a parameter, that then reads the file (four times) and returns a four element vector containing the four image matrices.
Note that the file write functions can also be used inside a programme. There is a little known variation of WRITEPRN / WRITEBIN, the one with the matrix listed at the end - WRITEBIN("file", "type", endian, [M]) that can be used.
This can be useful for creating test files!
I have recently asked that they (PTC/MathCAD) support multimage, 16 bit tiff format so that files I (& colleagues) receive from test gear don't need pre-processing.
I presume when you say 12 & 14 bit images you mean that the data has 12 or 14 valid bits within a 2-byte storage. This can cause confusion for some not familiar with local conventions.
On 7/21/2007 9:32:35 AM, philipoakley wrote: >Colin, >You should now be able to >combine the various parts >together.
Indeed! I've gotten everything integrated and the worksheets are working great. A big thanks to everyone who pitched in!!
> >In similar camera testing >environments I have found that >the 'browse for filename' >portion should be a single >stand alone button, (rather >than be inside a function) >because you want it to happen >the once, under user control, >and occur just the once in the >sheet. > >This compares with the >directory listing components >(see Richard's posts) which >are often better as functions, >as usually you want to >automatically go through all >the files in a directory.
I'm actually not using the dynamic listboxes for file selection anymore. They've been quite helpful in a few other spots, though.
>The four READBIN actions can >all be combined into one >function (programme) - just >pass in the file name as a >parameter, that then reads the >file (four times) and returns >a four element vector >containing the four image >matrices.
This would be a much cleaner method - but at this point, it works, and I'm hiding everything in locked areas anyway, heh.
>I have recently asked that >they (PTC/MathCAD) support >multimage, 16 bit tiff format >so that files I (& colleagues) >receive from test gear don't >need pre-processing.
pre-processing is awful. Before I discovered readbin(), it was THE WORST part of testing! That would be a very nice addition to Mathcad.
> >I presume when you say 12 & 14 >bit images you mean that the >data has 12 or 14 valid bits >within a 2-byte storage. This >can cause confusion for some >not familiar with local >conventions.