png snapshot of a specific swf frame - actionscript

I have two swfs. the first is my as3 application. the second one is contains 50 odd frames. The first swf has only two elements: a text box wherein the user types an integer (the frame number of the second swf actually) and a border container 100 x 300. When the user keys in an integer in the first swfs text box, I need to access the second swf from the first one, take a bitmap snapshot of the frame specified by the user, convert to png (minimum resolution 300 dpi) and display it inside the first swfs border container.
Can anyone guide me on how to take a bitmap snapshot (or convert) a specific frame of an external swf and pass it back to the master (controlling) swf?
Thanks

Related

Why can't I get a manually modified MPEG-4 extended box (chunk) size to work?

Overview
As part of a project to write an MPEG-4 (MP4) file parser, I need to understand how an extended box (or chunk) size is processed within an MP4 file. When I tried to manually simulate an MP4 file with an extended box size, media players report that the file is invalid.
Technical Information
Paraphrasing the MPEG-4 specification:
An MP4 file is formed as a series of objects called 'boxes'. All data is contained in boxes, there is no other data within the file.
Here is a screen capture of Section 4.2: Object Structure, which describes the box header and its size and type fields:
Most MP4 box headers contain two fields: a 32-bit compact box size and a 32-bit box type. The compact box size supports a box's data up to 4 GB. Occasionally an MP4 box may have more data than that (e.g., a large video file). In this case, the compact box size is set to 1, and eight (8) octets are added immediately following the box type. This 64-bit number is known as the 'extended box size', and supports a box's size up to 2^64.
To understand the extended box size better, I took a simple MP4 file and wanted to modify the moov/trak/mdia box to use the extended box size, rather than the compact size.
Here is what the MP4 file looks like before modifying it. The three box headers are highlighted in RED:
My plan was as follows:
Modify the moov/trak/mdia box
In the moov/trak/mdia, insert eight (8) octets immediately following the box type ('mdia'). This will eventually be our extended box size.
Copy the compact box size to the newly-inserted extended box size, adding 8 to the size to compensate for the newly inserted octets. The size is inserted in big-endian order.
Set the compact size to 1.
Modify the moov/trak box
Add 8 to the existing compact box size (to compensate for the eight octets added to mdia).
Modify the moov box
Add 8 to the existing compact box size (again, to compensate for the eight octets in mdia)
Here's what the MP4 file looks like now, with the modified octets are in RED:
What have we done?
We have told the MP4 parser/player to take the moov/trak/mdia box size from the extended field rather than the compact size field, and have increased all parent boxes by eight (8) to compensate for the newly-inserted extended box size in the mdia box.
What's the problem?
When I attempt to play the modified MP4 file I receive error messages from different media players:
Why do the media players see the modified file as invalid MP4?
Did I need to alter any other fields?
Does the extended box size have to be greater than 2^32?
Can it be that only specific box types support extended box size (e.g., Media Data)?
A tip of the hat to #Alan Birtles for pointing out that the chunk offsets would also need to be modified. Indeed, the stco (sample table chunk offset?) box contains absolute file offsets to the data chunks in the mdat box (rather than relative offsets within a box). This can be seen in the specification document:
The chunk offsets need to be increased by the number of octets we added to the file before the mdat box. In our case, this is the eight (8) octet extended box size inserted in the mdia box.
All that remained was to manually change the chunk offsets found in the two stco boxes (both video and audio tracks), adding eight (8) to each chunk offset. Here are the stco boxes before adding 8 to their chunk offsets:
Now the file passes validity tests of both the ffmpeg and ffprobe tools. Interestingly, although VLC succeeds in playing the modified file, other media players (e.g., Windows Media Player, MS Photos, MS Movies & TV, MS MovieMaker) report the file as corrupted. It is not clear why they fail to play the file. Unverified possibilities include:
Not supporting the extended box size for any box other than mdat
Balking if the extended box size is less than 2^32
In summary, if any fields are added to boxes (e.g., extended box size), the stco chunk offsets need to be incremented by the number of octets inserted in the MP4 file preceding each stco box.

TImagelist not adding bitmap

I'm at my whits end... trying to get a custom list of pictures, a TImageList and a TListView to work together. Original problem: No dynamically-added pictures are displayed in the list. Narrowed it down, problem is in the TImagelist. Code is below. ilMain is the TImagelist (defined elsewhere). Adding a bitmap to the list, immediatly retrieving it, first "Draw" works fine but the sedond fails... what am I missing here?
var i:integer;
test:TSch;
currentimage :TBitmap;
stupid :TBitmap;
begin
currentImage:=TBitmap.Create;
stupid:=TBitmap.Create;
ilMain.Clear;
// currentImage.LoadFromFile('C:\Delphi\piccat\pics\MonaLisa.jpg');
JPeg2Bmp('C:\Delphi\piccat\pics\MonaLisa.jpg',currentImage);
form1.canvas.Draw(100,10,currentimage);
ilMain.Add(currentimage,nil);
ilMain.GetBitmap(0,stupid);
form1.canvas.Draw(200,10,stupid);
EDIT:
Done some further testing on this one; results are very confusing and inconsistent.
Result are actually GREATLY dependant on the size of the input file (thanks for that pointer, kobik!); it seems everything smaller than 256x256 isn't imported into the imagelist, while bigger pictures ALONG THE X-AXIS are (sometimes??) spread over several items.
ilMain was set to 256x256 pixels.
Here is the output for several input sizes (X x Y, in pixels):
950x414
First draw displays entire image, second take 256x256 pixels in the upper left corner. HOWEVER, THREE items of the TImagelist are populated, with 3x 256x256 pixels: the three pictures that can be "cut out" from the main picture and still be 256x256 pixels. All edges cut off which are smaller, either vertical or horizontal, than 256x256 are lost.
1600x1600
Six images are imported; the first row of complete 256x256 blocks which can be cut from the top of the pic. The incomplete block on the tp right is omitted, and all rows below Y-size 256 as well.
1500x1000
Similar to previous one; five items imported now.
638x376
Again similar; only two items "fit" now.
197x256 (my original test file, described in post above)
NO ITEMS IMPORTED (X-size is smaller than TImaglist X-size?)
256x256
AGAIN, NO DATA IMPORTED
257x257
STILL NO DATA IMPORTED
260x260
STILL NO DATA IMPORTED
300x300
STILL NO DATA IMPORTED
512x256
Very weird one. One pic is imported; BUT it is reduced in size, so approximately 70% of the original pic fits in the (new) 256 X size. A black bar is added below the pic to make up for the lost space due to this shrinking.
So this is where I stop testing for now, and wondering if anyone can shed some light here...?
EDIT: Design part moved to new question (see request in comment kobik, thanks man!)
Your code works (or at-least needs to work) assuming your JPeg2Bmp is correct. I guess #Dima's second comment is correct.
You haven't showed the ilMain properties, and if you use the default you get an imagelist with Width/Height=16.
Try to omit the first call to form1.canvas.Draw(100,10,currentimage);, and draw only the form1.canvas.Draw(200,10,stupid); and You should see a 16x16 drawing at position 200,10.
TImagelist can't load arbitrary image sizes.
You need to pre-define it's size, and load the bitmaps with suitable sizes. i.e. create thumbnails to fit the imagelist dimensions.
Note also that (you probably know that) You need to draw only in response to WM_PAINT Message. e.g. in the Form OnPaint event.
EDIT: As regard to your edit, this is how TImageList works. if you add a bitmap that is larger than the imagelist width, it will attempt to break the bitmap into separate bitmaps to fit the imagelist size. this is by design.
See the documentation about ImageList_Add about the hbmImage parameter:
A handle to the bitmap that contains the image or images. The number
of images is inferred from the width of the bitmap.

UIImages losing dimensions and getting bigger in xcode

I am using xcode with Swift to develop a very simple application that should only run on iphone7. I have a bunch of UIImages and UIButtons with images in my application and I have received a bunch of PNGs to use in the application.
They are named more or less image1.png, image2.png and so on.
If I check the dimension of the PNGs, they look right to me.
For example one background image has the following dimensions: 750 x 1335.
Once I add this PNG to my application, and add it to the story board, the image looks huge.
I need to manually enter the following dimensions 350 x 887 (which is half the size) in order to get the image to fit the size of the phone on the screen.
I have no idea what is going on here! It is something I am doing wrong or it there something wrong with the exported PNGs?
I think you content mode is not right. This is how to fix it:
Click to your UIImageView
Look at the right hand side and choose View -> Content Mode to Aspect Fit
This is the document about content mode of a Image View
https://useyourloaf.com/blog/stretching-redrawing-and-positioning-with-contentmode/
I hope it can help you
iPhone's physical screen resolution is rarely referenced as is, instead it is calculated in points. On the early iPhones 1 point was actually 1 pixel. On modern iPhones 1 point is actually representing 2x2 pixels, or sometimes 3x3 pixels (for Plus models). To make it all work, all the graphics for UI elements (buttons and the like) are provided in two or three resolutions:
for the case where 1point = 1pixel
in such case the image name is not postfixed with anything (image1.png)
for the case where 1point = 2x2pixels
in this case the image name is postfixed with #2x (image1#2x.png)
for the case where 1point = 3x3pixels
in this case the image name is postfixed with #3x (image1#3x.png)
You have two ways of managing this.
First goes like this:
Rename all of your images, so that they all have #2x.png at the end. Like this:
image1.png becomes image1#2x.png
image2.png becomes image2#2x.png
Drag all those images to your Assets.xcassets folder in XCode:
Now you can assign the images to buttons, backgrounds, and pretty much anything else by calling its name (omitting the #2x at the end), like this: image1, image2, etc. The resolution will fit now.
You can also choose the images in drop-down lists in your Storyboard to apply them to different elements (like said buttons).
Second way is similar.
You don't rename the images, and drag them into the Assets.xcassets folder just as they are. Then you manually drag the thumbnails of your images into 2x slots. Here's an example with an image called 'gear':
For more information on how physical screen resolution of the iOS devices differs from its internal representation (which is in points), refer to this handy guide: https://www.paintcodeapp.com/news/ultimate-guide-to-iphone-resolutions

how to display image (containing text) with a good quality

I’m new in iOS and trying to make simple app with hierarchy of viewcontrollers. In the last one I wanna display scrollable image (which can also be zoomed at least x1,5), containing some small black and white picture and a piece of text. Initially I planned to make vector image, convert it to .jpg and use UIScrollView for displaying. But I found out that .jpg ( approx. 150 KB) didn’t provide a good quality for displaying text. As I have to use a lot of images I don’t want to increase image size. What is worse I also want it look good on retina display.
Can you recommend a way how to display image, containing text, with enough quality?
I mean that I don’t want the user see the separate pixels of letters in the text. Just like when you read text in your e-mail in iOS. Image size should be as small as possible. Planning physical size of image – approx. 5 cm x 15 cm.
Any help much appreciated
Thanks
To get good edges you would need to use png not jpg, which will make the image sizes much larger. I have a better suggestion, more code but better solution.
The answer is to not put the text into the image, but to draw it over it in real time.
You would:
associate text at some coordinate in the image (say a CGRect) with the image
create a uiimageview subclass that in the drawRect routine, after calling super, draws the text using the NSString categories on UIKit (which let you draw into a context)
To get going on this please create a small one vc project and get the subclass working there, then back port it to your primary project.

Maximum image dimensions in a browser/CSS spec?

I want to display a page containing about 6000 tiny image thumbnails (40x40 each). To avoid having to make 6000 HTTP requests, I am exploring CSS sprites, i.e. concatenating all these thumbnails into one long strip and using CSS to crop the required images out. Unfortunately, I have discovered that JPEG files cannot be larger than 65500 pixels in any one dimension. Wary of further limits in the web stack, I am wondering: are any of the following unable to cope with an image with dimensions of 40x240000?
Internet Explorer
Opera
WebKit
Any CSS spec
Any HTML spec
The PNG spec
Edit: the purpose of this is simply to display an entire image collection at once, requiring that the user at most has to scroll. I want the "micro-thumbnails" to flow into an existing CSS layout, so I can't just use a big rectangular image. I don't want the user to have to click through multiple pages to see everything. The total number of pixels is not that great - only twice what would fit on a 2560x1600 display. The total file size of all the micro-thumbnails is only a couple of megabytes. Assuming every image is manipulated uncompressed in the browser's memory, taking 8 bytes of storage per pixel (RGBA plus 100% overhead fudge factor), we are talking RAM usage in the low hundreds of megabytes; not unreasonable for a specialized application in the year 2010. The only unreasonable thing is the volume of HTTP requests that would be generated if all micro-thumbnails were sent individually.
Well, Safari/iOS lists these limits:
The maximum size for decoded GIF, PNG, and TIFF images is 3 megapixels.
That is, ensure that width * height ≤ 3 * 1024 * 1024. Note that the decoded size is far larger than the encoded size of an image.
The maximum decoded image size for JPEG is 32 megapixels using subsampling.
JPEG images can be up to 32 megapixels due to subsampling, which allows JPEG images to decode to a size that has one sixteenth the number of pixels. JPEG images larger than 2 megapixels are subsampled—that is, decoded to a reduced size. JPEG subsampling allows the user to view images from the latest digital cameras.
Individual resource files must be less than 10 MB.
This limit applies to HTML, CSS, JavaScript, or nonstreamed media.
http://developer.apple.com/library/safari/#documentation/AppleApplications/Reference/SafariWebContent/CreatingContentforSafarioniPhone/CreatingContentforSafarioniPhone.html
Based on your update, I'd still really recommend not using this approach. Don't you think there's a reason that Google's image search doesn't work like this?
As such, I'd recommend simply loading images as required via Ajax. (i.e.: When the user scrolls below the currently visible set of images.) Whilst this will use more connections, it'll mean that you can have sensibly sized thumbnails and as a general approach is much more manageable than having to re-generate pre-generated thumbnail image "sheets" on the back-end when a new image is added, etc.

Resources