GNOME Bugzilla – Bug 137327
gimp has problems reading incomplete png files
Last modified: 2007-02-16 13:24:39 UTC
Gimp doesn't read all the existing data in an incomplete png file, such as produced by an interrupted povray trace. gqview displays the same data which was on the screen at the time of interrupting the povray trace, but when opening the files in gimp, some of the data is missing eg 30-odd lines of data in a large 1800x2100 pixel image (size of intended complete image). Imagemagick convert also seems to have trouble. Perhaps here is a clue? I am not a programmer (TM) http://news.povray.org/povray.bugreports/thread/%3C3e2e3cf2$1@news.povray.org%3E/ It says that use of png_read_row() rather than png_read_image() was needed to fix a similar problem in povray itself. Stitching together of incomplete povray renders would save a lot of time, eg 140 hours to trace the complete image that I am having problems with. keyword: png libpng png_read_row png_read_image incomplete corrupt
Gimp does not handle broken PNG files, no surprise here :) I agree that it would be cool if GIMP can handle some broken PNGs, but this definitely is a low priority enhancement request. Please attach a small sample file with this problem, so that we have something to work on, but don't expect this to happen real soon now...
Generating an incomplete PNG file is very easy to do with POV-Ray: you simply have to interrupt a lengthy trace. I will try to have a look at this problem after the release of version 2.0.
Actually GIMP does handle incomplete PNG files (as the bug reporter states); it just doesn't handle all of them. The reason is that it reads them in chunks of 64 rows at a time (one tile-height's worth), and loses the last incomplete chunk when the data unexpectedly ends. I made a small change so that, for non-interlaced png files, the data are read one row at a time -- this should cause only the last row of an incomplete file to be missed. Would be nice if somebody who has such files on hand could check -- I don't. For cvs HEAD: 2005-02-25 Bill Skaggs <weskaggs@primate.ucdavis.edu> * plug-ins/common/png.c: read non-interlaced files one row at a time instead of in 64-row chunks; fixes bug #137327.
Doesn't this slow down reading of PNG images?
I don't see why it would make a noticeable difference. It's hard to say for absolute certain without looking at the guts of libpng, but there's no reason for the difference to be much more than the overhead of 64 function calls vs one function call. The documentation at http://www.libpng.org/pub/png/libpng-1.0.3-manual.html doesn't give any hint that there's any loss of speed by taking this approach.
I'd suggest that we take the fastest approach at reading the PNG and only fall back to reading it line-by-line if we encounter an error. It strikes me wrong that we need to support reading of corrupt images at all. Of course if it doesn't hurt the general case, then that's OK. But it definitely should not hurt the general case. If it turns out that the suggested approach is not feasible, I vote for reverting this change and closing this report as WONTFIX.
Looking at the libpng source, png_read_rows just calls png_read_row in a loop, so there really isn't any overhead. In fact, I'd suggest removing the if (num_passes == 1) bit and always reading individual rows, because the extra branch will lose some efficiency unless your compiler is smart.
Hm, given the above, how would this change help at all? There's no functional difference. The way to fix this is to load the image into gimp row by row (ick, slow) or let the error handler commit set_rect the incomplete pixel region. Reopening and setting to NEEDINFO so the reporter can provide an example of a corrupt image.
Okay, I agree with comment #8. Re comment #6, I think that given the overhead in creating an image, executing a plug-in, reading data from disk, and transferring the data from the plug-in to the core, it makes sense to trade speed for robustness where the loss of speed is too small to be noticeable by the user.
Just for information: there is now a semi-workaround for povray users for the case where they must produce an incomplete file: supplied by the povcomp team (see povcomp.com) a tool to take a partial pnm (not PNG) output render and turn it into a properly formed PNG file that gimp and other software can read. Simeon
We are still waiting for the bug-reporter to provide an example image. If such an image isn't provided soon, the report should be closed as INCOMPLETE.
sorry I didn't realise .. I'll look into providing one.
Will we see such an incomplete PNG anytime soon?
Created attachment 46116 [details] full version of test case pic - this one should load OK no matter what
Created attachment 46117 [details] a truncated file creatyed by using ctrl-c to interrupt a povray trace
Created attachment 46118 [details] povray partial trace - top portion of image only, specified using command line switch
Created attachment 46119 [details] povray partial trace - mid section of image only, specified using command line switch
Created attachment 46120 [details] povray partial trace - bottom portion of image only, specified using command line switch
Created attachment 46121 [details] povray partial trace - a block from the centre of image only, specified using command line switch
The relevent command line switches for povray are like this: povray +A0.3 +AM2 +R3 +GD +P +FN16 Display_Gamma=1.0 blood_sky_heart.pov +W340 +H400 +ER0.6 +SR0.3 +SC0.3 +EC0.6 +Oblood_sky_heart_small_sel.png SC and EC only used in the file http://bugzilla.gnome.org/attachment.cgi?id=46121&action=view The source file is available here: http://images.povcomp.com/entries/extras/210/blood_sky_heart_source.zip Currently I see that gimp loads these, but the file is corrupt after the truncation point - filled with wierdness on the screen. I didn't try editing etc to clean it up. I think this may be an improvement from when I logged the bug. Thanks, both retrospectively and in advance. :)
Applied in svn trunk: 2007-02-16 Mukund Sivaraman <muks@mukund.org> * plug-ins/common/png.c: improved handling of incomplete PNG files; fixes bug #137327.