My program loads a lot of images, but i have a problem with 1 image that used the print-screen button to copy it, from a game, however it is bmp, like all the rest. Whenever i run the program, it says project1.exe raised exception class Ereaderror with message 'stream read error' process stopped....
The code is this:
procedure TForm1.FormCreate(Sender: TObject);
var path, destination:string;
begin
path:=paramstr(0);
destination:=extractfilepath(path)+'Leagueoflegendsdesktop.bmp';
image1.Picture.LoadFromFile(destination);
end;
Which is correct. What do you suggest me?
The only explanation is that the file is not a valid Windows bitmap (maybe the file is truncated). Or perhaps the file uses some esoteric format not supported by Delphi. Is it using run-length encoding, for example.
If the file did not exist you'd get a different error, one that indicated that no such file exists. So, the file exists but cannot be loaded. Ergo, it's not a Windows bitmap.
Step 1 to diagnose this is to look at the format of the file. Load up the bitmap file header and check that the values make sense. Probably the easiest way to do this is to step through the VCL code when running your program under the debugger. Enable the Debug DCUs option so that you can do that. Set a breakpoint in TBitmap.ReadStream in the Graphics unit and take it from there.
Having said all that, it may just be easier for you to avoid trying to debug the problem at all. If you can load the image into an image editor, simply save a new copy of the image in a format that will be read by Delphi. For example a plain vanilla Windows bitmap, or, even better, a PNG file which will admit compression.
Related
First, full disclosure: I'm very new to coding and very new to file dissecting, but its something I anticipate studying in school very soon, so please pardon my ignorance in future interactions.
As a project I've decided to dissect the files of a mobile app I greatly enjoy. This app is Futurama: Worlds of Tomorrow. I'm a big fan of the cartoon, even spent money on the stuff, so I figured it was natural for me to pick.
Extracting the .apk file was easy, I found some of the assets they use in the game, like the music, the soundbytes, and some .pngs. All simple stuff.
However there are two files I'm absolutely baffled by: files with an .astc.czz extension and an .ita file that is not an italian read me file, the developers informed me that those are animation files.
Allow me to go into what I know and what I don't know:
Filename.astc.czz
Example file here
I recognize .astc as a compression file and was informed that .astc files are common for mobile games. Fair enough, but the real extension is .czz, the "real" extension of the file leads me to dead end. I've found the ASTC Evaluation Codec
by ARM-Software on github so I tried that. I changed the extension to .astc and then tried keeping .czz but the codec gives me an error every time. This is where I show my ignorance, I didn't know the right way to do this so I'm showing you every combination of what I tried. I replaced my name with user.
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.tga
File C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc not recognized
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d AC0001-dialogue1-003#2x.astc AC0001-dialogue1-003#2x.tga
File AC0001-dialogue1-003#2x.astc not recognized
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc.czz C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.tga
Failed to open file C:\Users\user\Downloads\astc-encoder-master\Binary\Win32\AC0001-dialogue1-003#2x.astc.czz
C:\Users\user\Downloads\astc-encoder-master\Binary\Win32
λ astcenc -d AC0001-dialogue1-003#2x.astc.czz AC0001-dialogue1-003#2x.tga
Failed to open file AC0001-dialogue1-003#2x.astc.czz
No success there.
So then I learned that .CZZ files are apparently associated with visECAD Viewer and I downloaded that and the .astc.czz files became associated with the program. I tried opening them but visECAD says it cant open them because they are "outdated." So that's another dead end.
Right, so that's all I know.
Filename.ita
Example file here
Out of curiosity I've actually emailed the developers about this file (and the astc ones too) and they said those are the animation of the game. They couldn't send me a viewer, which is perfectly fine, but I don't even know what .ita files are associated with that aren't italian read me's. Any insight would be appreciated, the animations are great and I would love to see them.
For full disclosure here are snippets of what the developers sent me:
Those strange file types are actually compressed files (like
".astc.ccz"). Different devices use different compression methods, so
we support many types to maintain low storage and memory usage. Some
devices don't use compression and just use .png versions of the same
file names.
The .lta files are the game's animations. I wish I could help you out
with viewing them, but there's no way for me to send you a viewer. :(
Well that's all folks, sorry it was so long, and thank you so much in advance. I'm grateful already!
I realise this is a few months old, but in case you're still interested, I've just cracked it. Basically, it's a compressed texture, the ccz part being the compression, and the astc being the texture format. I managed to decompress the file using QuickBMS (http://aluigi.altervista.org/quickbms.htm), using the following script for ccz files (copy the following into a txt file):
endian big
comtype zlib_dynamic
get ZSIZE asize
math ZSIZE - 0x10
get NAME basename
idstring "\x43\x43\x5a\x21"
goto 0xc
get SIZE long
clog NAME 0x10 ZSIZE SIZE
On running QuickBMS, it will first ask for a script, upon which point it to your new txt file. Then it will ask for the file you want to decompress, point it at your ccz file. Then it will ask where you want to save your astc file.
Now you will need a program that can open astc files! I used this one, Noesis: http://www.richwhitehouse.com/index.php?content=inc_projects.php&showproject=91
Find your astc file (the interface is quite straightforward), then from there you can double click the file to open it, then right-click and export to a variety of formats. For proof of concept, here is the extracted pf0001-action5-001#4xout (PF being Philip Fry I assume). https://www.dropbox.com/s/t2l3mesi2psbd1p/pf0001-action5-001%404xout.png?dl=0
Both programs allow for batch processing as well, so you should have everything you need! However, the lta files are skeletal animation I believe, so unfortunately the character animations are all in pieces. However, I'm looking into that next. Hope this helps!
EDIT: The above information is useful for your specific query, i.e. decompressing and reading the contents of those files. HOWEVER, if your end goal is to view the assets of the game, it's worth knowing that many of the assets are only downloaded AFTER the game is run, so looking in the "com.tinyco.futurama" on your Android voice will show all kinds of assets not present in the apk file. Many of them will be ready-extracted as well, being made ready for gameplay, so I would highly recommend copying the contents of this folder periodically. I think it re-compresses unused assets as well, so I would copy out the ccz files also, then either way you should reap the maximum benefits.
I want to be able to reference an image in a postscript file from a separate file location on my Xerox FreefLow print server rather than embed it into the postscript directly. This is to allow for print files that are very variable and have over a hundred variable images to choose from. I have tried using 'run exec' or 'GetTiff' Commands without success. Any advice on using VIPP postscript commands would be appreciated - postscript output is generated from PreS and PDF output is not an option.
Sample postscript I have tried
%!PS-Adobe-3.0
/Times-Bold findfont
20 Scalefont
setfont
200 450 moveto
(The Document Company Bryan) show
gsave
initgraphics
(/opt/XRXnps/resources/bf/czrdrf.ps.p000000001.ps) run exec)
grestore
showpagetext
I don't know anything about the Xerox Freeflow server, but I can offer some critique of your postscript code.
First, initgraphics should never be used in a document program. The graphics should already be initialized to the default settings by default, and if not, maybe it's because the code has been embedded into an altered context. Here, the only things altered are the current font (default is an invalid font), and defined the current point (default is undefined). Unless the embedded program depends upon these two elements of the graphics state to be undefined, there's no need to mess with resetting the state.
run runs the program in the named file. exec would only be needed if the result of the program file were a partially-evaluated procedure of some kind. I doubt this is the case. So my guess is that exec is causing a stackunderflow error and aborting the program. There should be some way to configure the server to report postscript errors back to you. Or error reports may be in a log file.
showpagetext is not a standard ps operator. showpage is.
I'd suggest you try with a simpler ps program, rather than the image program. First, we need to be sure that the file is accessible to the interpreter. So, we need to know if the error in the above program was actually stackunderflow as I suspect, or invalidfilename or invalidfileaccess or ioerror or something else.
If any or all of these efforts fail, there is an older postscript technique that you might consider. If the interpreter can create and write files, you can download the image by writing a program which writes the image program to disk. If that works, reading from the file later should also work.
I have a binary file that starts off with some data. After this data, the file has a JPEG image embedded in it. After the image, the file continues with some other data. I wish to use the image as an OpenGL texture.
At the moment, the only method I know of creating an OpenGL texture with Magick is to read the image file with Magick, write it into a blob, and upload the blob.data() to opengl (from this link: http://www.imagemagick.org/pipermail/magick-developers/2005-July/002276.html).
I am trying to use Magick++, but it only allows me to specify a filename, not a C-style filehandle or filestream...Are my only options the following? :
Save the JPEG image portion in the binary file as a separate temporary file and get Magick++ to read that image. I don't wish to do this as writing to disk will slow my program down.
Read the image portion into an array, create a Blob with the array as its data, and then read the Blob to obtain an image. I don't wish to do this either because after I get the image, I will need to again write the image data to another blob, and the entire code becomes unnecessarily long.
Switch to another library like DevIL, which offers support for what I want. Unfortunately, DevIL is not as feature rich as Magick.
I also looked into the core C API for Magick, where I can specify a filehandle, but the documentation says that the filehandle is closed by Magick after the image is read, which is definitely not good for my program (it is going to be pretty ugly to get the rest of my program to reopen the binary file to continue its processing...
If there is a way to provide Magick with custom I/O routines, or better still, a cleaner way of using Magick with OpenGL, please enlighten me!
The next release of GraphicsMagick does not close the input file handle after the image is read. You can try the latest development snapshot.
You could consider using mmap() (memory mapped file) to access the data and treat it as an in-memory BLOB using Magick++. The main issue with this is you might not know how long the data was in case you need to access data following the embedded JPEG image data.
It is trivial to add FILE* support to Magick++. The only reason I did not do so was for philosophical reasons (C++ vs C).
I can't copy the information in softice to disk/file. I am aware of IceExt but everytime I execute the command to dump the screen to disk(such as "!DumpScreen \??\c:\test.raw")it crashes my system entirely. When I try to copy with the mouse, the cursor only makes it possible to copy one line. I have already read through the softice manual. I just need a way to retrieve data from softice. Any help would be appreciated. I am using xp professional.
Turns out that no addons are required to accomplish this. Using the command "u cs:eip L 1000" from softice. You will then see a duplicate of the data within softice's screen displayed in the command window.
The u 'unassembles' code at the address cs:eip (the current EIP), the L specifies a length of 1000 bytes, you might need more than 1000 so adjust accordingly. Once you've done this you should exit SoftICE and select File / Save SoftICE History As from Symbol Loader, with any luck the resulting file will contain your code dump.You may have to to use F10 to step through inorder to get the data in softice's history log.
Using this method, I successfully dumped the entire code window and data window. The main drawback to this method is that the resulting text will contain alot of noise(unnecessary data). I haven't figured out how to get around this. This is a adaptation of woodmann's method.
I'm trying to create a backup of the Windows clipboard. Basically what I'm doing is using EnumClipboardFormats() to get all of the formats that exist on the clipboard currently, and then for each format, I'm calling GetClipboardData(format).
Part of backing up the data obviously involves duplicating it. I do that by calling GlobalLock() (which "Locks a global memory object and returns a pointer to the first byte of the object's memory block.") on the data returned by GetClipboardData(), then I fetch the size of the data by calling GlobalSize(), and then finally I do a memcpy() to duplicate the data. I then of course call GlobalUnlock() when I'm done.
Well, this works... most of the time. My program crashes at the GlobalLock() if the clipboard contains data with the format CF_BITMAP or CF_METAFILEPICT. After reading this Old New Thing blog post (https://devblogs.microsoft.com/oldnewthing/20071026-00/?p=24683) I found out why the crash occurs: apparently not all data on the clipboard is allocated using GlobalAlloc() (such as CF_BITMAP data), and so calling GlobalLock() on that data causes a crash.
I came across this MSDN article and it gives a list of clipboard formats and how they are freed by the system. So what I did was hard-code into my program all of the clipboard formats (CF_*) that are not freed by the GlobalFree() function by the system, and I simply don't back up those formats; I skip them.
This workaround seems to work well, actually. Even if a bitmap is on the clipboard, or "special" data (such as rows copied from Excel to the clipboard), my clipboard backup function works well and I haven't experienced any crashes. Also, even if there's a bitmap on the clipboard and I skip some formats during the backup (like CF_BITMAP), I can still Ctrl+V paste the originally-copied bitmap from the clipboard after restoring my clipboard backup, as the bitmap is represented by other formats on the clipboard as well that don't cause my program to crash (CF_DIB).
However, it's a workaround at best. My fear is that one of these times some weird format (perhaps a private one, i.e one between CF_PRIVATEFIRST and CF_PRIVATELAST, or maybe some other type) will be on the clipboard and my program, after calling GlobalLock(), will crash again. But since there doesn't seem to be much documentation explaining the best way to back up the clipboard, and it's clear that GlobalLock() does not work properly for all datatypes (unfortunately), I'm not sure how to handle these situations. Is it safe to assume that all other formats -- besides the formats listed in the previous URL that aren't freed by GlobalFree() -- can be "grabbed" using GlobalLock()?
Any ideas?
This is folly, as you cannot 100% backup/restore the clipboard. Lots of apps used delayed rendering, and the data is not actually on the clipboard. When you request to paste, they get notified and produce the data. This would take several minutes and hundreds of MB for large amounts of data from apps like Excel. Take a look at the number of formats listed on the clipboard when you copy from Excel. There will be more than two dozen, including Bitmap, Metafile, HTML. What do you think will happen if you select 255x25000 cells in Excel and copy that? How large would that bitmap be? Tip: save any open documents before attempting this, as you're likely going to have to reboot.