I have been looking for some PNGDecoder for a project I am working on, all was looking weird / complexe / dirty coded and hard to hunderstand, so last night and as often .... I've decided to reinvent the well and to built my own

- it support the 4 filter type for filter method 0- for now only decoding of RGB24 & RGB32 are implemented, but adding GREY & PALETTE one should be a kid game (5/6 code line more for each)- it is based on high efficiency & low memory usage (also did not allocate tones of buffer)- only critical chunks are decoded but extended should be pretty easy to add

even if it is a first shot and it still need some improvment, I have tried to make the code as clear as possible, and it may be of interrest to better understand PNG

NB : some object are missing as RGBArrayImage and Log but can be easily replaced

Sorry, I dont understand exacly what you means but I try an answer, so first about the implementation you can inded do whatever is possible to do with PNG format as it is a full decoder and than you can control what is done and how it is done.

about streaming and as far as I have understand :

=> PNG can break main data in several IDAT chunk => you can decode start of the image without the end => PNG doesn't allow uncompressing part of an image without uncompressing previous data (due to the zlib compression that compress the whole data once)

I dont get the point about scaling large image ?

ps: that's funny because I've worked on this decoder for such work (scaling huge streamed image) but not in the manner you descibe

if anybody get problem on using it due to lack of RGBArrayImage let me know, this is just an object that represent an RGB image (with or without Alpha) and can return its integer RGB or ARGB pixels array (can be easily replaced by a BufferedImage)

as PNG I never found any clear coded JPG Decoder, and unfortunatly JPG is not as simple as PNG...

may I ask what exacly are you looking for ? more details ?

Memory constraints. People are uploading photos, not knowing they are 4000x3000 pixels, and to make them usable, the server has to scale it back to a reasonable amount. Currently, for JPGs, I launch a seperate JVM with enough RAM to prevent OOME. I need massive heap because those 4000x3000 images take much more RAM than the expected 36MB. I keep the JVM heap of the 'real app' as small as possible to keep GCs down to millis, as garbage collections on heaps of >1024M are downright destructive for a somewhat-near-realtime app.

Besides server stuff, for some applets, I'm dealing with fixed size 64MB heaps, of which I have 10MB to spare for image resizing. The heap can be set to be bigger since 6u10, but I have to support 1.4

Anyway, long story short, reducing every MCU to 1 pixel would be my goal.

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

Anyway, long story short, reducing every MCU to 1 pixel would be my goal.

ok I better understand now, I think it is pretty doable (but may give some headack...)

may be have a look to this thread you posted in it some times ago, take a decoder and try to modify it.

reducing MCU to one pixel should not even requiere to perform IDCT : as if I am not wrong and if I remember well you look for the average color wich should be the frequency 0 (continous component signal) => the first FFT entries ( some explanation here ) (EDIT : hum... this is very only theorical... really not sure of what I said)

ok I better understand now, I think it is pretty doable (but may give some headack...)

may be have a look to this thread you posted in it some times ago, take a decoder and try to modify it.

reducing MCU to one pixel should not even requiere to perform IDCT : as if I am not wrong and if I remember well you look for the average color wich should be the frequency 0 (continous component signal) => the first FFT entries ( some explanation here ) (EDIT : hum... this is very only theorical... really not sure of what I said)

InputStream.skip() is like InputStream.read(byte[]) in that it might or might not read/skip the requested amount of bytes. You might be confused by the default implementation of the skip method, but things like FileInputStream and a Socket.getInputStream can/will have their own implementation that are more likely to skip less bytes.

I did not look to it yet, dont know how it is complexe,performing or well designed but at least it may this time enable "very very pure java PNG" decompression

When I wrote an M3G Loader for j2me (a work-around for phones that have serious bugs in their native M3GLoaders), I wrote a light weight zlib inflater (necessary because the M3G format uses DEFLATE streams in a similar way to PNG.)It was based upon the inflater code found in LodePNG.

Although the code is dire to read (and in C *shudder*), it was preferable to attempting to remove the OO structure (and thus bloat) from many of the existing zlib inflater implementations.When I was looking for a candidate library to rip-off, it became apparent that the kind of people who write zlib libraries are the same kind of people who are appalling at documenting their code!

clearly LodePNG is just horrible to read .... , no candidate to write a pure deflate ?? I looked the specs a little when I read you previous post it was seeming doable, dont know if it would requier a long time

here are the spec and as always they are hard to read... seems that people writing RFC/spec and such never found the bold/underline/etc... and other words editor like buttons....

I saw that the MINA apache networking project uses jzlib (http://www.jcraft.com/jzlib/) for zipping and I thought they must know the best choice so that's what I normally use too.

probably a good solution but too late now ! I have already started to work on my own, inded the main interrest is learning but it will be also cool to have a full pure java PNG, also deflating inflating seems to not requiere tones of code, I've fund a nice flash source code that may help me in this work.

the RGBArrayImage have really nothing fancy, I just did not want fullfill my first post :

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org