write_png inverted, /ORDER regression?

  • Porcelain Mouse

    Porcelain Mouse - 2012-08-09

    write_png was behaving normally before I upgraded to Fedora 17, which included GDL v0.9.2.  Now, write_png produces inverted/upside-down images.  Furthermore, the /ORDER keyword, which looks like it exists just for this purpose, does not re-invert the output image data.

    Is there something else I can do to produce the correct ordering?  Could this be a regression of bug ID 1545087?  Does some know why this behavior changed?

  • Alain C.

    Alain C. - 2012-08-09

    Thanks to several exchanges with other users, we made during last year large changes to the READ/WRITE JPEG/PNG. We think we reached a not that bad level in the current CVS version.
    (despite having now two new clearly identified problems: regression in ImageMagick in current Ubuntu 12.04,
    and a clear difference when reading the "Satrun.jpg" image in testsuite : two outputs depending on OS,
    to be clearly ASAP :(

    Could you consider to compile and test the current CVS version ? (because we changed not only the *pro but also the http://gnudatalanguage.cvs.sourceforge.net/viewvc/gnudatalanguage/gdl/src/magick_cl.cpp?sortby=date&view=log code)
    after install all the -devel- libs., magic lines are:
    mkdir gdl-0.9.2cvs120809
    cd gdl-0.9.2cvs120809

    cd gdl
    mkdir m4
    autoreconf -vfi
    make check

    for the options for "configure", e.g.: http://aramis.obspm.fr/~coulais/IDL_et_GDL/GDLonOSX_10.6.3.html
    if Cmake way:

    If not, could you download the files in the CVS under src/pro and test this revised version of "write_png.pro"

    And then download the files in testsuite, and test at least:
    - test_read_standard_images.pro (all 6 tests are OK on all OS except U 12.04)
    - test_image_statistics.pro to check wether you have a "regular" jpeg lib. (may help in later tests)

    If problem remains in the CVS version, we are ready to introduce changes and extra tests, it would help to have
    a (few) test(s) case(s), I think we can read then write and read again and check whether the diffs are null …
    (please give link to image and few lines of GDL syntax code.)


  • Alain C.

    Alain C. - 2012-08-09

    hum, in fact I was looking at WRITE_JPEG instead of WRITE_PNG (and made tests !!).

    yes, it seems that  WRITE_PNG  manages /order only for pure 2D images, not colors 3D. Please confirm !

    I will try to make a patch.


  • Porcelain Mouse

    Porcelain Mouse - 2012-08-09

    Hi Alain,

    Thanks for the quick reply!  I'm not sure I understand all the background on this issue, but I'm happy to help, if I can.  I'll try to test what's in CVS, but it might take me a little while.  I'll report here as soon as I do.

    In the short term, it sounds like some more details might be helpful.   Here is more accurate version information for GDL and ImageMagick on my system:

    ImageMagick 6.7.5-6 2012-03-06 Q16

    I'm not sure what you mean in your last post, but my problem occurs with a 2D image, not a 3D image.

  • Alain C.

    Alain C. - 2012-08-10

    good news/bad news

    good: the GDL version you have is a good one, thanks to Orion who packages kindly and with regularity GDL !

    bad: I found several bugs in WRITE_JPEG and WRITE_PNG, one example:

    GDL> a=dist(126,256)
    % Compiled module: DIST.
    GDL> write_jpeg, 'tyty.jpeg', a
    % Compiled module: WRITE_JPEG.
    % WRITE_JPEG: Scalar subscript out of range .5

    (and for write_png, in fact we create a pseudo 2D+1D image !!)

    I spend few time on the various problems, trying to fix at least the order and channel problems
    but the deeper I go more tricks I had :(

    On you side:
    - please try "test_read_standard_images.pro" in the CVS
    - if you need "write_PNG" for only a specific case, we can write a temporary version, I am afraid a more general code will not be ready in few days. Please



    PS: contributions welcome, please the test images we still use in "test_read_standard_images.pro", thanks !

  • Alain C.

    Alain C. - 2012-08-11

    I put in the cvs, under src/pro/, revised (improved !) versions of WRITE_JPEG and WRITE_PNG. Gray Scale (2D) and Colors images (3D) are OK now. I tested Order={0,1} too, it is OK for me (I read back testsuite/Saturn.jpg and write into JPEG or PNG, orientation is OK.)

    Unfortunately the way Gray images are managed is not optimal (in fact, 3D images are written). And I did not tested all the possible cases for input types (byte, int …) of "image". Not sure is Matte wroks well in PNG.

    Help and contributions welcome, please used the test images we still use in "test_read_standard_images.pro", thanks !

    Please report any trouble with details, because I did change details in "magick_cl.cpp" few months ago, and Image Magick is sometime "strange" (we have proofs !).



  • Porcelain Mouse

    Porcelain Mouse - 2012-08-14

    Hi Alain,

    Wanted to get something back to you in the short term, but I wasn't able to complete all the testing.

    1) The new write_png.pro is great.  It respects the /ORDER option-at least it does what I think it should do; my version also has code referring to the 'order' variable, but doesn't produce the expected result-which fixes my problem.

    I use tvrd() to get the image data from the X window buffer.  IDL docs suggest there is a !ORDER global variable which keeps tvrd() and write_png() "in sync", so to speak, regarding which orientation to read and write images.  I wonder if write_png should be written two use this global variable??  (If this is a stupid idea, please forget I mentioned it.)

    2) I couldn't compile GDL from CVS due to this error:
    libtool: Version mismatch error.  This is libtool 2.4 Debian-2.4-2ubuntu1, but the
    libtool: definition of this LT_INIT comes from libtool 2.4.2.
    libtool: You should recreate aclocal.m4 with macros from libtool 2.4 Debian-2.4-2ubuntu1
    libtool: and run autoconf again.

    That doesn't make any sense to me.  My /bin/libtool is not Debian-based, so I don't know what could mean.  And, I'm worried re-running autoconf will make things worse.  I may try it, though.  I could also try cmake, too…

  • Alain C.

    Alain C. - 2012-08-14

    for the 1/, I have to finish to make such kind of tests, yes
    What I tested up to now gave same behavior in IDL and GDL, but, for sure, it is limited set of tests.

    for the 2/, do you try the "autoreconf -vfi" before configure ?? (and if a stupide message about color-tests
    please change the line AM_INIT_AUTOMAKE(color-tests) into AM_INIT_AUTOMAKE in configure.in


  • Alain C.

    Alain C. - 2012-08-15

    Hum, I carefully read the code of TVRD and TV, we are not ready to support !order !!
    (it is not really difficult, just to have few quiet time …)


  • giloo

    giloo - 2013-10-08

    !ORDER and /ORDER are now (today's cvs) implemented in TV, TVSCL and TVRD.
    READ_JPEG and READ_PNG now check !ORDER too.


Log in to post a comment.