- Boost - lists.boost.org

Fwd: Formal Review of IO and Toolbox extensions to Boost.GIL starts TOMORROW
by Christian Henning 09 Dec '10

09 Dec '10

Hi Zach, > >>> There are some specific problems with the tests, though. For >>> instance, png_read_test.cpp takes an image file, reads it, then writes >>> it to a temporary file, then re-reads it from the temp file, and >>> compares the two read-in images for equality. This strikes me as a >>> bad test. It is quite possible to read an image, get the wrong >>> results, then write those wrong results to disk, re-read them, and >>> then have the re-read results compare equal to the original read >>> results. There may be other tests with a similar organization; I did >>> not check. >> >> This would assume that both png reader and writer have some bugs in >> common. I consider that less probable. > > No. > > Consider an image I that is solid red on the left half, and 0% alpha > on the right half, with a blue PNG background chunk. When loaded, it > should produce an image that is red on the left half, and blue on the > right half. > > Your PNG reading code ignores the background-color chunk (not a big > deal, as so does all other png reading code I've ever seen). I'll add this as an action item to my todo list. Although, with a lower priority. > > This means that when you read I, you get an image that is red on the > left, and transparent on the right. If you write that image to disk, > you have written an image that contains the wrong data (i.e. that is > different from the source image file). If you re-read it, it will > compare as equal to the initial read of the original image. You have > a correct writer, but an incorrect reader, and your test cannot detect > this. Yes, I agree not ideal. I have to think about what I can to better. > >>>> - Did you try to use the extensions? With what compiler? Did you have any problems? >>> >>> I only evaluated the PNG loading code, in an existing library that >>> already uses (a modified) GIL for image file loading. My library's >>> modified copy of GIL has numerous fixes to the PNG loading code. When >>> I substituted gil.io_new, I found that several files were again >>> unreadable. >> >> I just did a quick test with space_elevator.png you mention below. >> May it be that you forgot to set the BOOST_GIL_IO_ENABLE_GRAY_ALPHA >> symbol? The following code works just fine: >> >> #define BOOST_GIL_IO_ENABLE_GRAY_ALPHA 1 > > Yes, that was what I was missing. If only I had had the docs built, I > could have figured that out for myself. All the images in the > application now load correctly. > > What is the rationale for needing to define this? Why can't it be > always-on, or opt-out, instead of opt-in? gray_alpha lives in the toolbox and though it's not part of gil, yet. I'm just covering the case when a user only downloads io_new and not the toolbox. This compiler symbol should go away when io_new and toolbox are added to boost. Would you mind changing your vote? Assuming you changed your opinion. Regards, Christian

1 0

Workaround for compiler bugs
by Edward Diener 09 Dec '10

09 Dec '10

In attempting to write a library for Boost I have sometimes run into a given compiler's bug which prevents my work succeeding for a given compiler without a workaround. While I can, and have, gone to a compiler's NG or online forum to report the bug, and hopefully find a workaround, given the nature and difficulty of template metaprogramming there have often been no adequate responses. Of course I have worked to find a workaround on my own, but sometimes I can not find the "magic incantation" <g> to do so, while in other cases I can. Is this a valid NG for bringing such a compiler bug to light so that other Boost developers are not only aware of the bug but might have a solution, if they have not already developed one for themselevs ? Sometimes the bug peripherally involves some Boost library but often the bug just involves some sort of template, or template metaprogramming, construct which a particular compiler just can not handle correctly. In all cases the bug would have to do with some Boost-like library I am working on, preferably in the sandbox, else I would not feel justified in bringing up this issue in a Boost developer NG.

6 13

[gil io_new review] Reading images from in-memory sources
by Phil Endecott 09 Dec '10

09 Dec '10

> review of Christian Henning's extensions to the Boost Generic Image Library > starts on December 1st and lasts until December 10th, 2010. I've been looking at how to read images from in-memory data. For example, I have various places where I mmap() something that contains encoded images (e.g. a large map made up from many tiles in a single file). I can also imagine retrieving an encoded image from a database, for example. According to io.qbk: [h2 Reading And Writing In-Memory Buffers] Reading and writing in-mempory buffers are supported as well. See as follows: `` // 1. Read an image. ifstream in( "test.tif", ios::binary ); rgb8_image_t img; read_image( in, img, tiff_tag() ); // 2. Write image to in-memory buffer. stringstream out_buffer( ios_base::out | ios_base::binary ); rgb8_image_t src; write_view( out_buffer, view( src ), tiff_tag() ); // 3. Copy in-memory buffer to another. stringstream in_buffer( ios_base::in | ios_base::binary ); in_buffer << out_buffer.rdbuf(); // 4. Read in-memory buffer to gil image rgb8_image_t dst; read_image( in_buffer, dst, tag_t() ); In the cases that I described above, using a stringstream would require that all of the data is copied at least once. I guess that if I knew more about how streambufs work I would know how to avoid that. Can anyone help me to implement this: void read_mem_jpeg( some_gil_image_tpye& dest, const char* jpeg_mem_begin, const char* jpeg_mem_end) { ... } in a way that doesn't copy all of the encoded data? Looking at formats/jpeg/read.hpp, it seems that irrespective of that the data will be copied again (into 'buffer') before being read by libjpeg. On the subject of copying, while reading PNGs it looks like the data is always copied into a temporary buffer in read_rows<>() even when no format conversion is needed (or is there some specialisation that I have missed?). And when reading JPEGs, it seems to always read single lines, yet libjeg advises that you should get at least rec_outbuf_height lines on each call to avoid extra copying within the library. Regards, Phil.

6 16

Formal Review of IO and Toolbox extensions to Boost.GIL ends TOMORROW
by Mateusz Loskot 09 Dec '10

09 Dec '10

Dear All, The formal review of the IO and Toolbox extensions terminates tomorrow. I'd like to set the cut-off time at Midnight on Saturday, 11 December 2010, UTC Time (http://www.timeanddate.com/worldclock/fixedtime.html?day=11&month=12&year=2…) I think we have been doing well and received decent amount of feedback. However, anyone feels there is a need for extension, please let me know as soon as possible, so I will have time to negotiate it with the Review Wizards. Mateusz Review Manager for the proposed Boost.GIL.IO and Boost.GIL.Toolbox extensions On 30/11/10 18:01, Mateusz Loskot wrote: > Dear All, > > According to the Boost Formal Review Schedule [1], > review of Christian Henning's extensions to the Boost Generic Image > Library (Boost.GIL, [2]), it is: > * Boost.GIL.IO > * Boost.GIL.Toolbox > starts on December 1st and lasts until December 10th, 2010. > > [1] http://www.boost.org/community/review_schedule.html > [2] http://www.boost.org/doc/libs/release/libs/gil/doc/index.html > > =========== > What is it? > =========== > > The Boost.GIL.IO extension provides an easy to use interface for > reading and writing various image formats. It also includes > a framework for adding new formats. The Boost.GIL.IO is indent > to replace the current IO extension which is part of Boost > for several years now. > > Features: > > * A unified way to read and write image encoded in BMP, JPEG, > PNG, PNM, and TIFF formats. The capabilities to read and write > in various formats have improved dramatically. > > * Image data can be provided via standard file or string streams > > The Boost.GIL.Toolbox provides new color spaces > and other small code to ease programming with Boost.GIL. > > Features: > > * Implementation of color spaces: Gray_Alpha, HSL, HSV, LAB, and XYZ > * Utilities to support dynamic image workflows and color conversions. > * Collection of metafunctions to determine alignment, similarity > and homogeneity at pixel level. > > The Boost.GIL as well as the proposed extensions are provided in > form of a headers-only library Although, some image formats come with > their format dependency, it is corresponding third-party libraries: > > JPEG - libjpeg > PNG - libpng > TIFF - libtiff > > =================== > Getting the library > =================== > > The latest version of both extensions can be downloaded as > Zip package: > > http://gil-contributions.googlecode.com/files/boost_review.zip > > or directly from the Subversion repository: > > http://code.google.com/p/gil-contributions/source/browse/trunk/gil_2/ > > and the docs can built as usual with bjam and quickbook tools > from within libs/gil/io_new/doc directory > > The libs/gil/io_new/test/readme.txt provides a step by step guide to > configuring, building and running the unit tests. > > The boost_review.zip is about 20MB due to its extensive collection of > test images. They are part of the test suite to make sure that > different variations of each image format is read and > written correctly. > > Please, be aware no guarantee can be given that all formats in > their all variants are completely supported. > > ================ > Writing a review > ================ > > If you feel the new IO and Toolbox are interesting extensions > to the Boost.GIL library, then please submit your review > to the developer list (preferably), or > to the review manager (mateusz at loskot dot _n_e_t_) > > Here are some questions you might want to answer in your review: > > - What is your evaluation of the design? > - What is your evaluation of the implementation? > - What is your evaluation of the documentation? > - What is your evaluation of the potential usefulness of the > extensions? > - Did you try to use the extensions? With what compiler? Did you have > any problems? > - How much effort did you put into your evaluation? A glance? A quick > - reading? In-depth study? > - Are you knowledgeable about the problem domain? > > And finally, every review should answer this question: > > - Do you think the extensions should be accepted as a part > of Boost.GIL library? > > Be sure to say this explicitly so that your other comments don't > obscure your overall opinion. > > Mateusz > Review Manager for the proposed Boost.GIL.IO and > Boost.GIL.Toolbox extensions -- Mateusz Loskot, http://mateusz.loskot.net Charter Member of OSGeo, http://osgeo.org Member of ACCU, http://accu.org

1 0

Anyone got any ideas on Trac #2409? [ Boost::Optional; MSVS 9; one byte alignment ]
by Marshall Clow 09 Dec '10

09 Dec '10

Is this still a problem? It was reported against 1.36.0 https://svn.boost.org/trac/boost/ticket/2409 [ If someone could try to reproduce it, and add their results to the ticket, that would be great ] -- Marshall

1 0

[serialization] boost 1.45. I did not find any information about serios flaw in 1.44
by Sergey Voropaev 09 Dec '10

09 Dec '10

I am reporter of bug #4660 (https://svn.boost.org/trac/boost/ticket/4660) I am glad this bug was fixed in 1.45 version. But I did not find any information in release notes (http://www.boost.org/users/download/version_1_45_0) and in library documentation (http://www.boost.org/doc/libs/1_45_0/libs/serialization/doc/index.html) about what was fixed in 1.44 version. There are not any recommendations or comments about using version 1.44 with binary archives. I think that the absence of such information is very dangerous for the future of the serialization library, since this is a serious indicator of the quality of maintenance of the library. (I have no complaints about the quality of the library and its design) Should I reopen this bug, or open a new one, or this letter would be sufficient to restore order to the documentation of serialization library?

4 4

Boost on Sun CC without STLPort
by Martin Elzen 08 Dec '10

08 Dec '10

I've done a 'port' of one of our products which involved Boost 1.38. ... 0 or 1, using the Boost regex, system and filesystem libs with Sunstudio 12.0 (not the 'recent' .1 upgrade) on Solaris 10. To build Boost enabling the stlport option is a must (a certain Sun employee blogged about it a year or two ago). Unfortunately that will mean that all your other C++ code will need to be compiled with that same option. I did end up having to mess with one of the Boost system-ish files (maybe a .jam file) 'manually' to convert the -library=stlport4 option to -library=stlport4_dbg in 2 separate location in that file to get correct debugging libs. Except for that everything seemed to work fine at least as far as the Boost parts went...

1 0

copy on write for std containers
by Peter Foelsche 08 Dec '10

08 Dec '10

I wrote a couple of lines and replaced std::set and std::map with some copy-on-write-wrappers and I got a dramatic speed improvement with the last gcc 4.5. I think. My code was using recursive functions iterating over a tree returning and setting such objects. I looked and it seems there is nothing like this in boost! Ideally this should be an template argument for the std containers. Peter

6 11

Half-baked GIL IO extension review
by Edd Dawson 08 Dec '10

08 Dec '10

- How much effort did you put into your evaluation? A quick glance. I am interested in perhaps using the GIL in future and so keep half an eye on it, but I haven't yet had time to really sink my teeth in to it. I currently maintain a couple of C++ libraries for PNG and JPEG I/O [1][2] and wouldn't mind being released of the burden ;) So I'm really looking at the code to see whether it solves *my* problems. Hope that's ok. - What is your evaluation of the design? I think it's fine on the whole. But I'm left with some questions, some arising from real-world uses: 1. is there explicit support for reading images from files with Unicode file names? Or do I have to prepare a stream myself? I ask because there seem to be a lot of overloads for reading from files whose paths are specified by char*s and std::strings. IMO, in anything other than a toy application, these would be useless for writing portable code. And for toy code I'd probably use the PIL[3] (Python) instead. So for *me*, these functions are redundant. I'm aware of this redundancy because it exists in my code too :) 2. is it wise to drag the stuff from e.g. the IJG JPEG library's public headers in to client scope? I ask because I've had clashes with the "boolean" macro before and this would outright prevent me from using the library. The implication of addressing this would probably mean that the GIL would no longer be header-only. That's fine by me, but perhaps it's a design goal of the GIL for some reason? 3. Is there support for things like performing lossless JPEG rotations? Not a big deal to me right now, but potentially I would like to use such a facility in future. 4. Is there support for obtaining the real-world dimensions of a loaded raster in millimetres, say? I work on CAD/graphics applications which need this functionality in order to generate reasonable texture coordinates. - What is your evaluation of the implementation? Looking again at the JPEG code here. As far as I can tell setjmp/longjmp have been used with appropriate care, but I worry what will happen if a method on a Device throws an exception, for example. I've had both Visual C++ 2008 and Apple's g++ 4.0.1 crash on me in this kind of situation. In my code, I attempt to store an exception by doing something akin to boost::current_exception(), then longjmp out to a safe point before re-throwing it. The IJG JPEG library can be compiled as C++ code and there's some new stuff in Version 7 to control whether or not extern "C" blocks are used (look for DONT_USE_EXTERN_C in the IJG source). It would be desirable in my opinion to allow the user of the library the ability to use a build of libjpeg that was compiled as C++. If compiled in such a manner, with a little care it is possible to entirely replace setjmp/longjmp with exceptions. The same is true of libpng and possibly of libtiff. - What is your evaluation of the documentation? Couldn't find a lot. Either my eyes are poor, or the documentation is :) - What is your evaluation of the potential usefulness of the extensions? Potentially very useful. - Are you knowledgeable about the problem domain? I know little about the inner workings of the file formats and compression schemes involved, but have written my own C++ wrappers for libpng and the IJG JPEG library ('libjpeg'). - Do you think the extensions should be accepted as a part of Boost.GIL library? I personally couldn't use it until some of my concerns/requests were addressed. But I certainly think it could be of value to others as-is. However, I would say that there has to be more documentation, assuming I haven't simply missed it... For this reason, my answer at the moment is regrettably 'no'. I hope this was useful and my lack of general GIL knowledge doesn't invalidate too much of my evaluation. Kind regards, Edd [1] http://bitbucket.org/edd/pngxx [2] http://bitbucket.org/edd/jpegxx [3] http://www.pythonware.com/products/pil

5 14

Boost on Sun CC without STLPort
by Dean Michael Berris 08 Dec '10

08 Dec '10

Hi Everyone, Is there any specific reason why Boost isn't tested against Sun CC without STLPort -- aside from the obvious reason that there's nobody running the regression tests on that platform? Is it something inherently wrong in Sun's standard library implementation that's preventing Boost from working properly on the Sun compiler? Insights would be very much appreciated. Thanks in advance. -- Dean Michael Berris deanberris.com

7 14