Problem with streaked vertical lines

Mike Hardaker said:
Wow! If you save the image and then transfer it to a "known good" host (such as your Mac) are there any differences? Or is this a display issue alone?
Click to expand...

Let me check. Thanks.

I should say that my png resource that I load is only 256*256. I should try something larger too as that is unfair to the retina guy :)
 
The stripey test was using a 256*256 ramp. Here is what happens if I use a 2048*2048 ramp

This is the mini (non-retina)

magshift_mini7_2048.png


This is the mini retina

magshift_miniR7_2048.png

Painterly and stripey :)
 
I see the problematic behaviour occur on the following

iPad Air
iPad Mini Retina
iPhone 5S

... but not on these devices

iPad mini
iPod 5G
iPad 3 (retina) (thanks to my wife for the lend)

So just the modern 64 bit A7+ based devices ?

p.s. I tried both 64 and 32 bit builds on A7+ based devices.

p.p.s I need to try Mike H's image file suggestion
 
Mike Hardaker said:
Doesn't seem to be a problem on iPhone 5, either...
Click to expand...

Interesting.

As you suggested I wrote to a file on the last iteration and zinged it over to my Mac :

Code: 
 for( int i = 0 ;i < 25;i++ )
  {
  NSData* jpegrep = UIImageJPEGRepresentation( victim, compression );
   
  if( i == 24 ) [jpegrep writeToFile:[self testFilePath] atomically:NO];
   
  victim = [UIImage imageWithData:jpegrep];
  }

... and the resulting jpeg has the same artifacts

test.jpg


That's from the mini retina.
 
All of the devices I tested on were running iOS 7.0.6

I will update my mini retina to the latest beta and see how that affects things (thanks for the tips Pankaj)
 
Darren@RI said:
... and the resulting jpeg has the same artifacts
Click to expand...
Looks like the low-level 64-bit code for translating the Y'CrCb-encoded data to RGBA has an error. I'm wondering if Apple hasn't followed its own guidelines when porting from the 32-bit code and left behind an insufficiently-precise variable that once represented—say—a 32-bit number and is now being interpreted as a 64-bit number... ;-)
 
those are scary test results
seems like this is a combined hardware/software problem
wonder if we could get a poll from members on this thread - what device what software are people using, and see if it rings true in all those cases. then see if a list exists somewhere else on the net from users outside of MobiTog - particularly art photog ones which are very black&white oriented, as the issues are more apparent with less color involved...
 
Mike Hardaker said:
Looks like the low-level 64-bit code for translating the Y'CrCb-encoded data to RGBA has an error. I'm wondering if Apple hasn't followed its own guidelines when porting from the 32-bit code and left behind an insufficiently-precise variable that once represented—say—a 32-bit number and is now being interpreted as a 64-bit number... ;-)
Click to expand...

lol, yep ... shoulda used CGfloat :)
 
Darren@RI & Mike Hardaker & other participating MobiDevs - This is fascinating stuff guys and we certainly appreciate the efforts you are going to in investigating this problem, I am thinking you might be concluding that this may, after all, be an Apple oriented issue?

If so, as they will never listen to Joe Public, and assuming it is not going to be fixed by 7.1, how about you guys club it and let them know they need to resolve a rather serious and aggravating problem for their Mobile Photography customers, which must be a huge number of those iPhoneiPad owners?

Something must be done surely? And it seems you guys might stand the best chance of having them sit up and take note if you stand together... :rog:
 
Rolling your own UIImageJPEGRepresentation from ImageIO bits doesn't make any difference unsurprisingly.

Code: 
NSData* altJPEGRepresentation( UIImage* img, CGFloat comp )
{
  CFMutableDataRef buffer = CFDataCreateMutable(kCFAllocatorDefault,0);
   
  CGImageDestinationRef imgdest = CGImageDestinationCreateWithData(buffer, CFSTR("public.jpeg"), 1, NULL);
   
  NSMutableDictionary* options = [NSMutableDictionary new];
  options[ (NSString*)kCGImageDestinationLossyCompressionQuality ] = [[NSNumber alloc] initWithDouble:comp];
   
  CGImageDestinationAddImage(imgdest, [img CGImage], (__bridge CFDictionaryRef)options );
  CGImageDestinationFinalize(imgdest);
   
  return CFBridgingRelease(buffer);
}
 
So here's a plain English summary of the conversation so far :

There is a piece of code in iOS 7.0 that is used to load and save JPEG files (the prevalent format for photos in iPhoneography).

This Apple provided code is utilized in most photo apps (a recommended practice)

That code does not behave correctly when ran on the following devices :
  • iPhone 5S
  • iPad Air
  • iPad Mini with Retina Display
... causing unexpected lines and magenta shifts to appear in images.

Apple has said this problem has been fixed in the upcoming iOS 7.1 and this has been confirmed by several developers with access to test versions of 7.1
 
Darren@RI - So, rock on 7.1 then hey? ... :rog:

Great work between you guys, we are so privileged that our many Developer Members have joined in here and, hopefully, identified the cause, effect and cure... :notworthy:

Thank you all, so very much, for participating so much to this discussion, another awesome story... :notworthy:
 
You must log in or register to reply here.
Back
Top Bottom