Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

xArtx

macrumors 6502a
Original poster
Mar 30, 2012
764
1
Hi Guys,
My bundle has 4 images. These are there file sizes reported by Mac and Windows:

A = 32690 bytes
B = 49679 bytes
C = 67273 bytes
D = 188 bytes

I load them into an array in the app, for no other reason than to check their
file sizes match here:
Code:
    filePath = [[NSBundle mainBundle] pathForResource:@"mouse" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgsza = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"mousex" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszb = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"mousec" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszc = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"diskmask" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszd = [myData length];

Then I send the sizes to log here:
Code:
   NSLog(@"Size of Image A(bytes):%i",imgsza);
   NSLog(@"Size of Image B(bytes):%i",imgszb);
   NSLog(@"Size of Image C(bytes):%i",imgszc);
   NSLog(@"Size of Image D(bytes):%i",imgszd);

Then this is the log output:

2013-07-20 12:13:16.580 MegaBall[34508:907] Size of Image A(bytes):20695
2013-07-20 12:13:16.583 MegaBall[34508:907] Size of Image B(bytes):37369
2013-07-20 12:13:16.584 MegaBall[34508:907] Size of Image C(bytes):62424
2013-07-20 12:13:16.585 MegaBall[34508:907] Size of Image D(bytes):204

What's going on here?
I haven't even loaded them to UIImage objects yet.
This is strictly looking at file size.
 
Hi Guys,
My bundle has 4 images. These are there file sizes reported by Mac and Windows:

A = 32690 bytes
B = 49679 bytes
C = 67273 bytes
D = 188 bytes

Reported how? What tool?

Did you use the 'ls -l' command ('dir' on Windows)? Something else?

Is your posted log output produced from the simulator? An on-device run? Something else?

Be specific.


If you used Finder's Get Info on OS X, then be aware that there may be additional data (xattrs, Finder info, resource fork) associated with a file. This will contribute to Finder's reported sizes, but will not appear under 'ls -l'. The 'ls -l' command only reports the length of the data fork, which is also what you get when you use dataWithContentsOfFile:.

If you want another way to check file size (data fork length), use the low-level C function stat() and give it a Posix pathname in a C string. The length of the data fork will be in the st_size struct member.

To see if a file has xattrs, read the man page for the xattr command:
Code:
man xattr
For the online man page, google search terms: os x man page xattr
 
Reported how? What tool?

Did you use the 'ls -l' command ('dir' on Windows)? Something else?

Is your posted log output produced from the simulator? An on-device run? Something else?

Be specific.


If you used Finder's Get Info on OS X, then be aware that there may be additional data (xattrs, Finder info, resource fork) associated with a file. This will contribute to Finder's reported sizes, but will not appear under 'ls -l'. The 'ls -l' command only reports the length of the data fork, which is also what you get when you use dataWithContentsOfFile:.

If you want another way to check file size (data fork length), use the low-level C function stat() and give it a Posix pathname in a C string. The length of the data fork will be in the st_size struct member.

To see if a file has xattrs, read the man page for the xattr command:
Code:
man xattr
For the online man page, google search terms: os x man page xattr

What I mean is, I can open the png files in a hex editor,
and the first figures are the actual file sizes in bytes.
The pngs were created in Windows, and moved to the Mac for Xcode.
Same as get info with Mac, or right click-> Properties for Windows.

I repeated the same thing with files other than images,
and they are correct.
Test was done on iPhone 5 device.

Perhaps Xcode could do additional compression on pngs at compile time.
They are all smaller.

It's supposed to be a test of the images in the bundle for anti-tamper on JB device.

----------

Bingo:
http://stackoverflow.com/questions/...essresources-build-step-for-xcode-iphone-apps

So long as this is done at compile time... the sizes should be consistent
when run across all devices and iOS versions I think.
 
Should mention that there's a change to iOS 7 Jpeg compression,
or at leas tho whatever it's default compression setting or quality is.

I was checking the array size of a Jpeg representation matches
what I expect it to be (in byte size, not image dimensions).
This is the same with every iOS on every device until iOS 7 beta.

So I have an app in the store ready to break when iOS 7 arrives to the public
if I don't get the update approved first.
 
Hi Guys,
My bundle has 4 images. These are there file sizes reported by Mac and Windows:

A = 32690 bytes
B = 49679 bytes
C = 67273 bytes
D = 188 bytes

I load them into an array in the app, for no other reason than to check their
file sizes match here:
Code:
    filePath = [[NSBundle mainBundle] pathForResource:@"mouse" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgsza = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"mousex" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszb = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"mousec" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszc = [myData length];
    
    filePath = [[NSBundle mainBundle] pathForResource:@"diskmask" ofType:@"png"];
    myData = [NSData dataWithContentsOfFile:filePath];
    imgszd = [myData length];

Then I send the sizes to log here:
Code:
   NSLog(@"Size of Image A(bytes):%i",imgsza);
   NSLog(@"Size of Image B(bytes):%i",imgszb);
   NSLog(@"Size of Image C(bytes):%i",imgszc);
   NSLog(@"Size of Image D(bytes):%i",imgszd);

Then this is the log output:



What's going on here?
I haven't even loaded them to UIImage objects yet.
This is strictly looking at file size.

The build process for iOS runs a utility called pngcrush on png files before copying them into the iOS bundle.

If your source files are uncompressed PNG files, they will be smaller in the iOS bundle. However, pngcrush does not compress as much as a program like PS does, so compressed PNG files will actually grow as a result of the pngcrush step.
 
The build process for iOS runs a utility called pngcrush on png files before copying them into the iOS bundle.

If your source files are uncompressed PNG files, they will be smaller in the iOS bundle. However, pngcrush does not compress as much as a program like PS does, so compressed PNG files will actually grow as a result of the pngcrush step.

It looks like it did them ok, I only removed transparency, they might have started with a low compression level.
It was silly to create a jpeg representation and do the file check on that.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.