×

Discussion Board

Results 1 to 6 of 6
  1. #1
    Registered User
    Join Date
    Jan 2008
    Posts
    4

    Red face Byte primitive limit in saving Images to RMS

    Hi,

    I am digging into a problem that I have in downloading, saving and retrieving images on certain phone types.

    My Images are held remotely and are downloaded via servlets and then stored on the phone using J2ME RMS.

    This works fine for Nokia, Sony, Blackberry and most other PDA devices, However I have problems with LG and Samsung phones.

    On looking at this problem I am confronted with a fairly basic problem.

    If you examine the byte information in the actual PNG image data in memory it can contain values such as 89 (Hex Byte) which equates to 137 (decimal) this is the % symbol (default ascci).

    Retrieving the information from the server using a stream ( in = new BufferedInputStream(new FileInputStream(fin)) returns a stream of integers (int) and the values returned are OK i.e 137 comes back as 137

    However if you try to convert this int to a Byte you will get a negative value (-119) obviously because int can only have a value up to 127 and when the most significant bit is set it becomes negative.

    My question is how can you convert the downloaded PNG image data to a byte array without corrupting it??

    Obviously some phones including Nokia can manage this corruption and still display the image, but others (including the Sun standard colour-phone emulator do not)

    It is also possible that I am doing something completely stupid. If so could someone reply with a few lines of code showing how to do this properly.


    Thanks

  2. #2
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Byte primitive limit in saving Images to RMS

    This is not your problem. 137 and -119 are exactly the same pattern of bits. If it was a problem, createImage(byte[], int, int) would never work. And it (largely) does.

    Your problem is something else.

    It's possible that there is some problem in downloading the data across the network. Or, possible that there is some RMS problem. Devices impose limits on the maximum RMS available to an application, the maximum number of record stores, and the maximum size of a single record.

    I will mention one issue that appears on some LG devices, using createImage(byte[], int, int)... on some LGs, this fails if the offset is not zero. This causes problems when several PNG streams are packed into a single byte array.

    However, you mention that the WTK emu is giving problems too.

    Many devices are fussy about format. Especially, many devices have problems with PNG images that have transparency, and are less than 8 bits per pixel. 8 bit per pixel images give the best compatibility. Try changing the format of the image, to 256 colour PNG.

    Another problem occurs when the PNG has a transparent colour, and an opaque colour with the same RGB values. On some Samsungs, the opaque colour will become transparent also. Make sure that the RGB values of any transparent colour do not match any of the opaque colours. This most often happens when the transparent colour is black or white... the popular practice of using bright magenta for transparent usually makes this go away.

    Some Samsung devices "dither" colours in an annoying way.

    Few devices display 16 million colours, so colours in a PNG will be approximated to the closest the device can display. On devices with limited colour (Nokia 7210, 4096 colours), images with many close colour-shades will look a bit crap.

    If none of these describe your problems, then it would help to have a copy of the PNG file, a picture of how it appears on the device, and the model number of the device.

    Cheers,
    Graham.

  3. #3
    Registered User
    Join Date
    Jan 2008
    Posts
    4

    Re: Byte primitive limit in saving Images to RMS

    Graham,

    Many thanks for your response. I have investigated some of the suggestions that you proposed, however I am still stumped,and this forum will not allow me to attach a sample image as you suggested. If you are able and willing I can e-mail an image and code samples. You can get me at jim@thenaq.co.uk

    I have lived with this problem for over 6 months now and I really do appreciate your help.

    Rgds Jim

    The Networks

    I dont think that the Networks are playing up. I can get the images to work with Nokia,Sony and Blackberry across all 4 major UK Networks (even O2 PAYG!). Virgin et al are another matter, but I'm not really concerened with them at the moment.

    Image Size / RMS constraints

    I have created test images as small as 3x3 pixels (PNG Image size approx 165 bytes) but I still get the problem. I am also not storing large numbers of records.

    Byte array offset

    I am indeed combining multiple images and text in one stream, but nowhere do I have an offset in createImage(byte[], int, int)... HOWEVER I wonder if the problem has anything to do with encoding.
    From the phone I detect the character set supported and include this when sending to the Servlet. The Servlet detects this and then sends back using the same encoding. I would have thought that the encoding will not affect the basic byte[] data, but there is a point during parsing on the phone where I convert the Byte[] received from the Servlet to a String (to extract associated text) and then I convert back again to a a byte[] to store the image. Could the encoding used here be the issue?



    I have modified the images to be 256 colours, but the problem persists.

    The error message thrown by the WTK emu is as below (All other emulators including LG work fine)

    javax.imageio.IIOException: Unknown row filter type (= 61)!
    at com.sun.kvem.png.PNGImageReader.decodePass(Unknown Source)
    at com.sun.kvem.png.PNGImageReader.decodeImage(Unknown Source)
    at com.sun.kvem.png.PNGImageReader.readImage(Unknown Source)
    at com.sun.kvem.png.PNGImageReader.read(Unknown Source)
    at com.sun.kvem.midp.GraphicsBridge.loadImage(Unknown Source)
    at com.sun.kvem.midp.GraphicsBridge.createImageFromData(Unknown Source)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
    at java.lang.reflect.Method.invoke(Unknown Source)
    at com.sun.kvem.sublime.MethodExecution.process(Unknown Source)
    at com.sun.kvem.sublime.SublimeExecutor.processRequest(Unknown Source)
    at com.sun.kvem.sublime.SublimeExecutor.run(Unknown Source)
    java.util.zip.ZipException: invalid distance code
    at java.util.zip.InflaterInputStream.read(Unknown Source)

    The problematic phones are Samsung SGH 600 and LG KU990

  4. #4
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Byte primitive limit in saving Images to RMS

    Yes, I'm tempted to suggest encoding (or some other network related issue).

    However, I'd expect the decoder to break at some earlier point, rather than the row filter. Also, row filter is the kind of thing that a lot of devices are likely simply to ignore. (Some devices don't even check the chunk CRCs.)

    I've sent you a mail, if I can see the PNG file, something might be apparent.

    Cheers,
    Graham.

  5. #5
    Regular Contributor
    Join Date
    May 2008
    Location
    Copenhagen, Denmark
    Posts
    84

    Re: Byte primitive limit in saving Images to RMS

    Quote Originally Posted by grahamhughes View Post
    Many devices are fussy about format. Especially, many devices have problems with PNG images that have transparency, and are less than 8 bits per pixel. 8 bit per pixel images give the best compatibility. Try changing the format of the image, to 256 colour PNG.
    Hi Graham, just a side-note about image formats. I've never had problems with my PNG-24's, all my tested handsets can read them.
    How do you get PNG images with less than 8-bit alpha? Sure a PNG-8 only has on/off - hmm, I don't understand that sentence

    But you're off course right that many devices have problems displaying colors & alpha correctly due to hardware limitations and bugs (*cough* SonyEricsson W810i)

    /Steel

  6. #6
    Super Contributor
    Join Date
    Jun 2003
    Location
    Cheshire, UK
    Posts
    7,395

    Re: Byte primitive limit in saving Images to RMS

    Quote Originally Posted by Steel_BRS View Post
    I've never had problems with my PNG-24's, all my tested handsets can read them.
    Occasionally, I think you need to use them. I avoid them simply because they tend to be larger.

    Quote Originally Posted by Steel_BRS View Post
    How do you get PNG images with less than 8-bit alpha? Sure a PNG-8 only has on/off - hmm, I don't understand that sentence
    PNG always has full alpha. That PNG uses "index transparancy" (like GIF) is a myth. Essentially, PNG palettes are 32 bit (ARGB), with the slight quirk that the main palette-chunk contains only RGB, and the alpha is in a separate (optional) alpha-chunk. Alpha default to 0xff (fully opaque) for any palette-chunk entry that has no corresponding alpha-chunk entry.

    Cheers,
    Graham.

Similar Threads

  1. Preventing write-access to NFC tag
    By Jazz66 in forum Near Field Communication
    Replies: 4
    Last Post: 2009-06-25, 11:11
  2. Saving Mutable Images in RMS
    By amalshah73 in forum Mobile Java General
    Replies: 1
    Last Post: 2009-01-19, 11:55
  3. Opening secure channel from the applet doesnot work with Nokia 6131
    By sujithkjoseph in forum Near Field Communication
    Replies: 0
    Last Post: 2008-06-05, 13:51
  4. what is an APDU
    By pawangjain in forum Near Field Communication
    Replies: 0
    Last Post: 2007-07-02, 07:42
  5. Loading images from byte array on 6130i
    By enlightment in forum Mobile Java General
    Replies: 2
    Last Post: 2002-06-05, 19:44

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
×