hi list,
first, thanks for providing matplotlib, i am using it in several projects.
i had problems with several png files and decided to upgrade libpng.
this broke matplotlib.
as you can see in the documentation of libpng15, it is no longer possible
to directly access png_infop.
i have created the following patch:
--- matplotlib-1.0.1/src/_png.cpp 2010年10月12日 16:14:42.000000000 +0000
+++ matplotlib-1.0.1X/src/_png.cpp 2011年05月25日 19:23:36.261752651 +0000
@@ -350,18 +350,21 @@
png_set_sig_bytes(png_ptr, 8);
png_read_info(png_ptr, info_ptr);
- png_uint_32 width = info_ptr->width;
- png_uint_32 height = info_ptr->height;
+ png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
+ png_uint_32 height = png_get_image_height(png_ptr, info_ptr);
- int bit_depth = info_ptr->bit_depth;
+ int bit_depth = png_get_bit_depth(png_ptr, info_ptr);
// Unpack 1, 2, and 4-bit images
if (bit_depth < 8)
png_set_packing(png_ptr);
+ // this is needed several times, so safe it in a variable
+ png_byte color_type = png_get_color_type(png_ptr, info_ptr);
+
// If sig bits are set, shift data
png_color_8p sig_bit;
- if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE) &&
+ if ((color_type != PNG_COLOR_TYPE_PALETTE) &&
png_get_sBIT(png_ptr, info_ptr, &sig_bit))
{
png_set_shift(png_ptr, sig_bit);
@@ -374,13 +377,13 @@
}
// Convert palletes to full RGB
- if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
+ if (color_type == PNG_COLOR_TYPE_PALETTE)
{
png_set_palette_to_rgb(png_ptr);
}
// If there's an alpha channel convert gray to RGB
- if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
+ if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
{
png_set_gray_to_rgb(png_ptr);
}
@@ -408,11 +411,11 @@
npy_intp dimensions[3];
dimensions[0] = height; //numrows
dimensions[1] = width; //numcols
- if (info_ptr->color_type & PNG_COLOR_MASK_ALPHA)
+ if (color_type & PNG_COLOR_MASK_ALPHA)
{
dimensions[2] = 4; //RGBA images
}
- else if (info_ptr->color_type & PNG_COLOR_MASK_COLOR)
+ else if (color_type & PNG_COLOR_MASK_COLOR)
{
dimensions[2] = 3; //RGB images
}
@@ -421,7 +424,7 @@
dimensions[2] = 1; //Greyscale images
}
//For gray, return an x by y array, not an x by y by 1
- int num_dims = (info_ptr->color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;
+ int num_dims = (color_type & PNG_COLOR_MASK_COLOR) ? 3 : 2;
double max_value = (1 << ((bit_depth < 8) ? 8 : bit_depth)) - 1;
PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(
kind regards,
dieter
On 05/25/2011 10:53 AM, Dieter Schön wrote:
> hi list,
>
> first, thanks for providing matplotlib, i am using it in several projects.
>
> i had problems with several png files and decided to upgrade libpng.
> this broke matplotlib.
> as you can see in the documentation of libpng15, it is no longer possible
> to directly access png_infop.
>
> i have created the following patch:
Dieter,
Thank you, but the modification has already been made to the master
branch. I did not consider this as a bug fix, so I applied it only to
master, not to the maintenance branch.
Eric
>
> --- matplotlib-1.0.1/src/_png.cpp 2010年10月12日 16:14:42.000000000 +0000
> +++ matplotlib-1.0.1X/src/_png.cpp 2011年05月25日 19:23:36.261752651 +0000
> @@ -350,18 +350,21 @@
> png_set_sig_bytes(png_ptr, 8);
> png_read_info(png_ptr, info_ptr);
>
> - png_uint_32 width = info_ptr->width;
> - png_uint_32 height = info_ptr->height;
> + png_uint_32 width = png_get_image_width(png_ptr, info_ptr);
> + png_uint_32 height = png_get_image_height(png_ptr, info_ptr);
>
> - int bit_depth = info_ptr->bit_depth;
> + int bit_depth = png_get_bit_depth(png_ptr, info_ptr);
>
> // Unpack 1, 2, and 4-bit images
> if (bit_depth< 8)
> png_set_packing(png_ptr);
>
> + // this is needed several times, so safe it in a variable
> + png_byte color_type = png_get_color_type(png_ptr, info_ptr);
> +
> // If sig bits are set, shift data
> png_color_8p sig_bit;
> - if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE)&&
> + if ((color_type != PNG_COLOR_TYPE_PALETTE)&&
> png_get_sBIT(png_ptr, info_ptr,&sig_bit))
> {
> png_set_shift(png_ptr, sig_bit);
> @@ -374,13 +377,13 @@
> }
>
> // Convert palletes to full RGB
> - if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE)
> + if (color_type == PNG_COLOR_TYPE_PALETTE)
> {
> png_set_palette_to_rgb(png_ptr);
> }
>
> // If there's an alpha channel convert gray to RGB
> - if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
> + if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA)
> {
> png_set_gray_to_rgb(png_ptr);
> }
> @@ -408,11 +411,11 @@
> npy_intp dimensions[3];
> dimensions[0] = height; //numrows
> dimensions[1] = width; //numcols
> - if (info_ptr->color_type& PNG_COLOR_MASK_ALPHA)
> + if (color_type& PNG_COLOR_MASK_ALPHA)
> {
> dimensions[2] = 4; //RGBA images
> }
> - else if (info_ptr->color_type& PNG_COLOR_MASK_COLOR)
> + else if (color_type& PNG_COLOR_MASK_COLOR)
> {
> dimensions[2] = 3; //RGB images
> }
> @@ -421,7 +424,7 @@
> dimensions[2] = 1; //Greyscale images
> }
> //For gray, return an x by y array, not an x by y by 1
> - int num_dims = (info_ptr->color_type& PNG_COLOR_MASK_COLOR) ? 3 : 2;
> + int num_dims = (color_type& PNG_COLOR_MASK_COLOR) ? 3 : 2;
>
> double max_value = (1<< ((bit_depth< 8) ? 8 : bit_depth)) - 1;
> PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew(
>
>
> kind regards,
> dieter
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Matplotlib-devel mailing list
> Mat...@li...
> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel
On 05/25/2011 05:36 PM, Eric Firing wrote: > On 05/25/2011 10:53 AM, Dieter Schön wrote: > >> hi list, >> >> first, thanks for providing matplotlib, i am using it in several projects. >> >> i had problems with several png files and decided to upgrade libpng. >> this broke matplotlib. >> as you can see in the documentation of libpng15, it is no longer possible >> to directly access png_infop. >> >> i have created the following patch: >> > Dieter, > > Thank you, but the modification has already been made to the master > branch. I did not consider this as a bug fix, so I applied it only to > master, not to the maintenance branch. > It seems to have been applied to the maintenance branch... Maybe someone backported it? https://github.com/matplotlib/matplotlib/blob/v1.0.x/src/_png.cpp Mike > Eric > > >> --- matplotlib-1.0.1/src/_png.cpp 2010年10月12日 16:14:42.000000000 +0000 >> +++ matplotlib-1.0.1X/src/_png.cpp 2011年05月25日 19:23:36.261752651 +0000 >> @@ -350,18 +350,21 @@ >> png_set_sig_bytes(png_ptr, 8); >> png_read_info(png_ptr, info_ptr); >> >> - png_uint_32 width = info_ptr->width; >> - png_uint_32 height = info_ptr->height; >> + png_uint_32 width = png_get_image_width(png_ptr, info_ptr); >> + png_uint_32 height = png_get_image_height(png_ptr, info_ptr); >> >> - int bit_depth = info_ptr->bit_depth; >> + int bit_depth = png_get_bit_depth(png_ptr, info_ptr); >> >> // Unpack 1, 2, and 4-bit images >> if (bit_depth< 8) >> png_set_packing(png_ptr); >> >> + // this is needed several times, so safe it in a variable >> + png_byte color_type = png_get_color_type(png_ptr, info_ptr); >> + >> // If sig bits are set, shift data >> png_color_8p sig_bit; >> - if ((info_ptr->color_type != PNG_COLOR_TYPE_PALETTE)&& >> + if ((color_type != PNG_COLOR_TYPE_PALETTE)&& >> png_get_sBIT(png_ptr, info_ptr,&sig_bit)) >> { >> png_set_shift(png_ptr, sig_bit); >> @@ -374,13 +377,13 @@ >> } >> >> // Convert palletes to full RGB >> - if (info_ptr->color_type == PNG_COLOR_TYPE_PALETTE) >> + if (color_type == PNG_COLOR_TYPE_PALETTE) >> { >> png_set_palette_to_rgb(png_ptr); >> } >> >> // If there's an alpha channel convert gray to RGB >> - if (info_ptr->color_type == PNG_COLOR_TYPE_GRAY_ALPHA) >> + if (color_type == PNG_COLOR_TYPE_GRAY_ALPHA) >> { >> png_set_gray_to_rgb(png_ptr); >> } >> @@ -408,11 +411,11 @@ >> npy_intp dimensions[3]; >> dimensions[0] = height; //numrows >> dimensions[1] = width; //numcols >> - if (info_ptr->color_type& PNG_COLOR_MASK_ALPHA) >> + if (color_type& PNG_COLOR_MASK_ALPHA) >> { >> dimensions[2] = 4; //RGBA images >> } >> - else if (info_ptr->color_type& PNG_COLOR_MASK_COLOR) >> + else if (color_type& PNG_COLOR_MASK_COLOR) >> { >> dimensions[2] = 3; //RGB images >> } >> @@ -421,7 +424,7 @@ >> dimensions[2] = 1; //Greyscale images >> } >> //For gray, return an x by y array, not an x by y by 1 >> - int num_dims = (info_ptr->color_type& PNG_COLOR_MASK_COLOR) ? 3 : 2; >> + int num_dims = (color_type& PNG_COLOR_MASK_COLOR) ? 3 : 2; >> >> double max_value = (1<< ((bit_depth< 8) ? 8 : bit_depth)) - 1; >> PyArrayObject *A = (PyArrayObject *) PyArray_SimpleNew( >> >> >> kind regards, >> dieter >> >> ------------------------------------------------------------------------------ >> vRanger cuts backup time in half-while increasing security. >> With the market-leading solution for virtual backup and recovery, >> you get blazing-fast, flexible, and affordable data protection. >> Download your free trial now. >> http://p.sf.net/sfu/quest-d2dcopy1 >> _______________________________________________ >> Matplotlib-devel mailing list >> Mat...@li... >> https://lists.sourceforge.net/lists/listinfo/matplotlib-devel >> > > > ------------------------------------------------------------------------------ > vRanger cuts backup time in half-while increasing security. > With the market-leading solution for virtual backup and recovery, > you get blazing-fast, flexible, and affordable data protection. > Download your free trial now. > http://p.sf.net/sfu/quest-d2dcopy1 > _______________________________________________ > Matplotlib-devel mailing list > Mat...@li... > https://lists.sourceforge.net/lists/listinfo/matplotlib-devel > -- Michael Droettboom Science Software Branch Space Telescope Science Institute Baltimore, Maryland, USA
On 05/26/2011 04:40 AM, Michael Droettboom wrote: > On 05/25/2011 05:36 PM, Eric Firing wrote: >> On 05/25/2011 10:53 AM, Dieter Schön wrote: >> >>> hi list, >>> >>> first, thanks for providing matplotlib, i am using it in several projects. >>> >>> i had problems with several png files and decided to upgrade libpng. >>> this broke matplotlib. >>> as you can see in the documentation of libpng15, it is no longer possible >>> to directly access png_infop. >>> >>> i have created the following patch: >>> >> Dieter, >> >> Thank you, but the modification has already been made to the master >> branch. I did not consider this as a bug fix, so I applied it only to >> master, not to the maintenance branch. >> > It seems to have been applied to the maintenance branch... Maybe > someone backported it? Mike, I think you did--unintentionally! If you look at the graph with qgit (or presumably any other such tool) in the vicinity of your commits on May 6, you will see that this one a50874b711983cba505ecdb2801c4996eccf3812 made v1.0.x branch off of master; the v1.0.x line was broken by the previous commit. To confirm that this break had the effect of propagating the change in _png.cpp into what is now v1.0.x, you can look at the diff between two commits on "v1.0.x", one of which is a bit before the break, the other after: git diff 069c21d 0e6dad src/_png.cpp You will see that the file was changed. Eric > > https://github.com/matplotlib/matplotlib/blob/v1.0.x/src/_png.cpp > > Mike
On 05/26/2011 03:19 PM, Eric Firing wrote: > > Mike, > > I think you did--unintentionally! If you look at the graph with qgit > (or presumably any other such tool) in the vicinity of your commits on > May 6, you will see that this one > > a50874b711983cba505ecdb2801c4996eccf3812 > > made v1.0.x branch off of master; the v1.0.x line was broken by the > previous commit. To confirm that this break had the effect of > propagating the change in _png.cpp into what is now v1.0.x, you can look > at the diff between two commits on "v1.0.x", one of which is a bit > before the break, the other after: > > git diff 069c21d 0e6dad src/_png.cpp > > You will see that the file was changed. > > Eric > I'm still not sure what happened there, and even less sure how to resolve it. Does this mean we have a bunch of other things from master in v1.0.x as well? Mike
On 05/27/2011 05:02 AM, Michael Droettboom wrote: > On 05/26/2011 03:19 PM, Eric Firing wrote: >> >> Mike, >> >> I think you did--unintentionally! If you look at the graph with qgit >> (or presumably any other such tool) in the vicinity of your commits on >> May 6, you will see that this one >> >> a50874b711983cba505ecdb2801c4996eccf3812 >> >> made v1.0.x branch off of master; the v1.0.x line was broken by the >> previous commit. To confirm that this break had the effect of >> propagating the change in _png.cpp into what is now v1.0.x, you can look >> at the diff between two commits on "v1.0.x", one of which is a bit >> before the break, the other after: >> >> git diff 069c21d 0e6dad src/_png.cpp >> >> You will see that the file was changed. >> >> Eric >> > I'm still not sure what happened there, and even less sure how to > resolve it. Does this mean we have a bunch of other things from master > in v1.0.x as well? Mike, I wouldn't worry about it. It seems likely that other things from master did leak into v1.0.x, but at this point I don't think it matters. v1.0.x and master both build and run (or did last time I checked). The division between the two is somewhat arbitrary anyway. Tracking down and reversing the leakage, if there is any other than the _png.cpp change (which certainly does no harm in v1.0.x), would not be worthwhile. Better to just move forward, make improvements, and get some good releases out. Eric > > Mike >
On 2011年5月27日 07:29:15 -1000, Eric Firing wrote: [clip] > I wouldn't worry about it. It seems likely that other things from > master did leak into v1.0.x, but at this point I don't think it matters. > v1.0.x and master both build and run (or did last time I checked). > The division between the two is somewhat arbitrary anyway. Tracking > down and reversing the leakage, if there is any other than the _png.cpp > change (which certainly does no harm in v1.0.x), would not be > worthwhile. This probably was already clear to everybody, but you can find out what came in the merges: If no force-pushes have been made, and only one merge was mistaken, then there is a single merge commit that brings *all* of the mistakenly merged commits into the commit graph. 1) Locate the merge that pulled lots of stuff, e.g., with http://pav.iki.fi/tmp/git-merge-pull-history git merge-pull-history -l upstream/v1.0.x|less 14406a68c appears to be the first one combining stuff both from master and v1.0.x. 668ef6d8 is a red herring as it shows a merge from already contaminated v1.0.x. 2) git show 14406a68c commit 14406a68c039dc6578730f23955bf34d34008a08 Merge: fdf5fae 132f967 ... 3) What was pulled in from master to v1.0.x: git log --oneline fdf5fae ^132f967 git diff 132f967 fdf5fae
On 05/27/2011 08:31 AM, Pauli Virtanen wrote: > On 2011年5月27日 07:29:15 -1000, Eric Firing wrote: > [clip] >> I wouldn't worry about it. It seems likely that other things from >> master did leak into v1.0.x, but at this point I don't think it matters. >> v1.0.x and master both build and run (or did last time I checked). >> The division between the two is somewhat arbitrary anyway. Tracking >> down and reversing the leakage, if there is any other than the _png.cpp >> change (which certainly does no harm in v1.0.x), would not be >> worthwhile. > > This probably was already clear to everybody, but you can find > out what came in the merges: > > If no force-pushes have been made, and only one merge was mistaken, > then there is a single merge commit that brings *all* of > the mistakenly merged commits into the commit graph. > > 1) Locate the merge that pulled lots of stuff, e.g., with > http://pav.iki.fi/tmp/git-merge-pull-history > git merge-pull-history -l upstream/v1.0.x|less > Pauli, Nice--but what exactly is the meaning of "left" and "right"? Is it true that if all best practices were followed, there would be no "left to right" commits pulled? Is "master" always farthest left? Eric
On 2011年5月27日 09:51:37 -1000, Eric Firing wrote: [clip] > Nice--but what exactly is the meaning of "left" and "right"? When you write git checkout this-branch git merge other-branch the left parent of the new merge commit is `this-branch` and the right one is `other-branch`. The "commits pulled" just means the commits that are in the DAG of one parent but not in that of the other. I just pulled the terminology out from thin air... > Is it true that if all best practices were followed, there would > be no "left to right" commits pulled? No: if you have this situation: --A-------B main branch \ C----D topic branch and merge the topic branch back to the main branch, you will get merges to "both" directions, with "B" appearing left-to-right. If you rebase first on B, then you will get only right-to-left, though. > Is "master" always farthest left? Not necessarily if things like this have been done: git checkout v1.0.x git merge upstream/master git push upstream HEAD:master This would give the same result as git checkout master git merge upstream/v1.0.x git push upstream master but with an inverted order of the parents. If the merge command is used in the natural way, the "trunk" of the branch tends to be on the left, and right-to-left merges show what new was merged to it. But you can manually change this order, and this seems to have occurred in this case. Pauli