Image file sizes reported wrong

Discussion in 'iOS Programming' started by xArtx, Jul 19, 2013.

  1. xArtx macrumors 6502a

    Joined:
    Mar 30, 2012
    #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:

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

    Joined:
    Aug 9, 2009
    #2
    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
     
  3. xArtx thread starter macrumors 6502a

    Joined:
    Mar 30, 2012
    #3
    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.
     
  4. xArtx thread starter macrumors 6502a

    Joined:
    Mar 30, 2012
    #4
    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.
     
  5. Duncan C macrumors 6502a

    Duncan C

    Joined:
    Jan 21, 2008
    Location:
    Northern Virginia
    #5
    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.
     
  6. xArtx thread starter macrumors 6502a

    Joined:
    Mar 30, 2012
    #6
    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.
     

Share This Page