Discussion in 'Additional Libraries' started by dzt, Dec 24, 2007.
Thanks - I thought not. There do seem to be some around, but a quite an impressive price.
First stab at an image processing library. Does contrast, brightness, B&W and colour invert. Have a play. Can easily add gamma correction in the future as it already linearises colour values for internal processing assuming the standard sRGB gamma of 2.2 and reapplies the same gamma on output. Applying a different gamma would be trivial.
Give that man another award right now!
That was really quick, really helpful & really useful! :sign0188:
Hugely updated version 1.2 of image processing library posted in its' own thread.
Long time no chat. Hope everything's going well for you.
Sneaky question, can your image library be modified to add
transitions, such as fade-in/out for slide shows?
Don't tell me you can do it.
Any chance you'd be willing to add a JPEGtoByteArray (or similar) function? I am using dzImage to take screenshots and I need to send them over the network. So, essentially I am looking for a way to get JPEG data for a screenshot without writing to a file.
Thanks much for your work on this library.
All the best,
Have a look at this:
I think this is what you are looking for.
Thanks for the response. I took a look at that thread but did not find a solution to my problem. I may have overlooked it.
Perhaps my questions is better explained with code. My goal is to take a screenshot, convert the BMP screenshot data to JPEG, then send the JPEG data across a TCP socket connection. I would like to avoid saving the image to a file in order to do the JPEG conversion. This is how my code looks for sending BMP data:
'BMPU is part of my custom protocol
header() = bit.StringToBytes("BMPU ",0,5)
'CRLF used to terminate commands and transfers
terminator() = bit.StringToBytes("</terminator>" & Chr(13) & Chr(10),0,15)
'Capture Screen Image
'Send protocol command
'Send Image Data
What I would like to be able to do is something like this:
'Send Image Data
I appreciate any help you can offer.
Thanks again for your time,
Try this Brian. The only way (native to .NET) to get a JPG is to save a bitmap to a file or stream, you can't get access to the encoded bytes directly. This tiny library tries to save a bitmap to a stream.
EDIT :- Note that your device may not support saving a JPG. Not all do.
In trying to use sahoops Screen Capture App, I have a problem on my device.
I found that there is a problem with the SaveImageXXX functions on my Qtek 9090.
I get the message below.
I have added a small test code.
On the device, I can even not load this code in B4PPC.
Does anyone know what is wrong, do I missing some part of .NET 2 ?
Thank you in advance.
I get the same on my Axim X30. It seems that not all devices appear to support saving anything other than BMPs even though the MS documentation for the Compact Framework implies that they should. However SaveImageBMP should work.
You are right, SaveImageBMP does work.
I have modified the test code for the three image formats.
Thank you very much for posting the BitmapStreamSaver! I'll just need to add a fallback to BMP for incompatible devices. For thos devices that are compatible, this will be a big performance boost.
It's almost :sign0008: for me.
I have successfully used the following code from the Desktop IDE v6.05, but I cannot compile. The compiler shows error CS1026: ) Expected on the following line:
I suspect it is because I am calling mystream.new2 (I tried New1 as well) in the SaveImageToStream call. I tried creating the stream and just handing it to the SaveImageToStream call, as below:
(This code compiles, but does not actually function. When I run the compiled executable, it complains that Stream2 was not assigned any value)
Any ideas as to where my syntax has gone wrong? Here is a more complete example sequence:
As a side note, the unoptimized compiler will compile this code, but the compiled app does not send image data on desktop and complains on the device about an optionally assembly that cannot be found.
Thanks very much for all the help so far. It is truly appreciated.
I don't know what sort of object "my stream is" but I think it is unnecessary, just pass the stream from your client to the function.
"New" methods don't generally return anything so are not valid as parameters in calls to Subs.
This an error, the missing assembly contains complete error messages, caused by another error that therefore cannot be displayed. The missing assembly is sometimes not installed to save space. See here http://www.basic4ppc.com/forum/showthread.php?t=870
Huge thanks to agraham!
Sorry it took me so long to respond; my workload got the best of me.
I now have a (mostly) working remote control agent for PPC. It looks like the Treo 750 is one of those devices that doesn't natively support saving to JPEG. Fortunately I was able to fall back on BMP.
I sincerely appreciate the time and effort of everyone who responded to my questions.
Have a great weekend,
I have since found an authoritative quote from Microsoft that only WM5.0 and later support saving other formats than BMP. The OS DLL in WM2003 can apparently do it but the OS code to exploit it was omitted for some reason.
In using sahoopes CapSure Screenshot program I noticed a strange behaviour with the saved bitmaps.
Saved with the SaveImageBMP routine of the dzImage library.
As shown in the picture below, the original file Wine1dz.bmp is displayed upside down with ACDSee thumbnails, but it's normal in the viewer.
The vaHelpMaker doesn't recognize this file.
I copied it into Paint, selected the whole image and saved it back under Wine1.bmp and this file is OK.
I compared both files with Total Commander, and
- the bitmap width F0 00 00 00 (240 pixels) is OK
- the height 40 01 00 00 (320 pixels) is OK in the Wine1.bmp file
- but in the Wine1dz.bmp file it looks strange C0 FE FF FF (complementary value) ?
Has anybody experienced the same problem, or is it also due to WM 2003 as for saving jpg and gif format which do not work either?
Included the zip file with the 2 bmp files.
Thanks in advance.
Nothing to do with that, that was an omission. Bitmaps in files can be saved top down or bottom up, normally bottom up. Wikipedia - "Uncompressed Windows bitmaps can also be stored from the top row to the bottom, if the image height value is negative". It looks like for some reason the Compact Framework saves bmps top down - I have no idea why! Apps may or may not interpet this correctly if they don't expect negative values.
Thank you for the explanations, now I understand better what's behind.
I was not aware that bitmaps could also be saved top down with a negative height value.