When I try to call SaveToFile method on TPNGImage object I get Acces Violation Error.
PNG Construction:
pngTest:=TPngImage.CreateBlank(COLOR_GRAYSCALE, 16, 2048, 2048);
Method Call: pngTest.SaveToFile('testtttt.png');
PNG object is created correctly because I can assign it to TImage and it works.
This is a defect in the Delphi PNG library code. Please report it to Embarcadero.
The defect seems to be triggered by the use of 16 bit colour depth. If you switch the code to use 8 bit colour then the code runs successfully.
There's no simple workaround, and so you'll need to find a different PNG library if you wish to continue with 16 bit colour. I would expect that Microsoft's Windows Imaging Component library will function correctly. Or you might consider Graphics32 with the GR32PNG extension.
Related
I am trying to use C++ AMP in Visual C++ 2017 on Windows 10 (updated to the latest) and I find the archived FFT library from C++ AMP team on codeplex. I try to run the sample code, however the program throws ran out of memory error when creating DirectX FFT. I solve that problem by following the thread on Microsoft forum.
However, the problem doesn't stop. When the FFT library tries to create Unordered Access View, it throws error of CLIPBRD_E_CANT_OPEN. I did not try to operate on clipboard anyhow.
Thank you for reading this!
It seems I solve the problem. The original post mentioned that we need to create a new DirectX device and then create accelerator view upon it. Then I pass that view to ctor of fft as the second parameter.
fft(
concurrency::extent<_Dim> _Transform_extent,
const concurrency::accelerator_view& _Av = concurrency::accelerator().default_view,
float _Forward_scale = 0.0f,
float _Inverse_scale = 0.0f)
However, I still have crashes of the CLIPBRD_E_CANT_OPEN.
After reading the code, I realize that I need to create array on that DirectX views too. So I started to change:
array<std::complex<float>,dims> transformed_array(extend, directx_acc_view);
The idea comes from the different behaviors of create_uav(). The internal buffers and the precomputing caused no problem, but the samples' calls trigger the clipboard error. I guess the device matters here, so I do that change.
I hope my understanding is correct and anyway there is no such errors now.
I'm using AdonisJS framework, and it has its own method move(), that uses fs.
The issue is that when making use of this method, the image that's moved is corrupted, and when oepning it, this message is shown:
Error interpreting JPEG image file (Not JPEG file: starts with 0xef 0xbf)
The documentation I based on is this, so my code is no much different than it.
I am using cvBlobsLib library for a blob detection work, however, i am facing a crash in the program in the code.
My code crashes at this point:
CBlobResult blobs;
blobs = CBlobResult(imageSkinPixels, NULL, 0);
imageSkinPixels must be a single-channel image: in other words, you need to convert your RGB image to GRAY before passing it to CBlobResult().
Also, we don't know what is the type of imageSkinPixels, but it should be a pointer to IplImage.
That's all I can say with the code you shared. If this doesn't fix the problem you'll need to share more code.
I am trying to create a Delphi 6 program with DSPACK that records audio from the PC input devices (Windows XP) and then writes the captured audio to a MS format WAV file. The problem I am having is that I am getting NIL back when I try to get the legacy filter named 'WAV Dest':
CapEnum.SelectGUIDCategory(CLSID_LegacyAmFilterCategory);
filWaveDest.BaseFilter.Moniker := CapEnum.GetMoniker(CapEnum.FilterIndexOfFriendlyName('WAV Dest'));
filWaveDest.BaseFilter.Moniker contains NIL after these calls. How can I correct this since obviously subsequent code that attempts to write the WAV data captured using filWaveDest fails?
Wav Dest is not a standard DirectShow filter. It is an example filter in the SDK. Either build the object or download a copy of the DLL someone else has built.
The situation is this:
I've written a simple MovieClip replacement that converts an existing imported MovieClip to a sequence of BitmapData. This removes the requirement for Flash to render vector data in the MovieClip on each frame.
But BitmapData has a huge memory footprint. I've tried converting the BitmapData to a ByteArray and using the compress() method. This results in a significantly smaller memory footprint. But it has proven impractical. For each redraw, I tried uncompressing()'ing the ByteArray, then using SetPixels to blit the data to the screen, then re-compressing() the frame. This works but is terribly slow.
So I was wondering if anybody else has an approach I could try. In Flash, is it possible to compress bitmap data in memory and quickly blit it to the screen?
I wonder how native animated GIFs work in Flash. Does it uncompress them to BitmapData behind the scenes, or is frame decompression done on the fly?
Perhaps there is an Alchemy project that attempts to blit compressed images?
Thanks for any advice you can offer :)
#thienhaflash's response is good but has aged a year and since then Flash Player and AIR Runtime have expanded their capabilities. Today I stumbeled on this little tidbit from Adobe's AS3 Guide. As of player 11.3 there are native image compression techniques available. Here's a snippet:
// Compress a BitmapData object as a JPEG file.
var bitmapData:BitmapData = new BitmapData(640,480,false,0x00FF00);
var byteArray:ByteArray = new ByteArray();
bitmapData.encode(new Rectangle(0,0,640,480), new flash.display.JPEGEncoderOptions(), byteArray);
Not sure about the practicality for blitting but it's nice that it can be done natively.
For memory reservation you need to think twice before convert a MovieClip to a Bitmap sequence. Is it really that need ? Can you break things down as there are several things (like the background) is static (or just moving around) why don't cache bitmap for each elements instead of one big Bitmap sequence ?
I usually used AnimatedBitmap (the name for bitmap sequence alternative for a MovieClip) only for small size animated icons, and other heavy calculation stuffs (like fire / smoke effects ...). Just break things down as much as you can !
As far as i know, there are no way to compress the memory used by a BitmapData located in the memory and there are nothing related to Alchemy could help improve memory used in this case.
Animated GIF won't works in Flash natively, you will need some library to do that. Search for AnimatedGIF as3 library from bytearray.com, actually the library just read the gif file in raw byteArray and convert to an animatedBitmap just like how you've done.
this is an old question, but there is recent info on this : jackson Dunstan has had a run with bitmapdatas and it turns out that Bitmap data obtained from compressed sources will "deflate" after some time unused.
here are the articles : http://jacksondunstan.com/articles/2112, and the two referred at the beginning of it.
So you could absolutely do something like :
var byteArray:ByteArray = new ByteArray();
myBitmapData.encode(new Rectangle(0,0,640,480), new flash.display.JPEGEncoderOptions(), byteArray);
var loader = new Loader();
loader.addEventListener(Event.COMPLETE, function(_e:Event):void{
if(loader.content is Bitmap){
myBitmapData.dispose()
myBitmapData= Bitmap(loader.content).bitmapData;
}
});
loader.loadBytes(byteArray);
I'm not sure if it would work as is, and you definitely want to handle your memory better. but now, myBitmapData will be uncompressed when you try to read from it, and then re-compressed when you don't use it for about ten seconds.