05-07-2009 08:15 AM - edited 05-07-2009 08:16 AM
Here is my first shot at doing some "bit twiddling" it's close but it's not outputting the same results. Can you guys take a look at it to see if i'm loosing my bits?
05-07-2009 09:20 AM
I found the problem of why it was not outputing the same numbers... the Bit Position in conjunction with the MSB need to be in I32 representation, they were in U32. My mistake. The reason why it needs to be I32 is because I depend on the negative number it creates to shift the bits in the correct direction before it "OR"'s the data together.
But even though its outputing correctly now, am I handling the data correctly or is there a better way of moving the bits around?
Thanks,
Branson
05-07-2009 10:51 AM
I just wanted to point out that LabVIEW is inherently multithreaded. When your wires fork, so do the threads. After that, it's up to the OS to divide up the work amongst cores.
Seems fine, but I second getting a bigger hard drive. They're pretty inexpensive these days! ![]()
05-07-2009 11:27 AM
So, it seeme you are having 32 bit images here. If they are 24 bit color, you might just trim it down to 24 bits. If they are monochrome, you should make them 8 bit paletted.
How well do the images compress, e.g. with zip?
05-07-2009 01:36 PM
I am compressing a binary image, and stuffing it into the actual picture it came from, as well as other sorts of identification about the image. A typical binary image saved by itself in TIF format is 1MB, in PNG format is 51kB, in ZIP format of a TIF file is 33kB, in Packed Binary format using IMAQ Flatten to String.vi is 131kB, and my version of compression is 34kB with 15ms run time.