Just one more thing the fact that a single RGB seems to work when you have a kind of semi-transparency a layer is easily explained because one is saving only the RGB resulting from the merge operation no need to save the alpha value (becauuse at the end you have a pixel with a color resulting from the merging operation) . But in order to have a semi-transparent background or full transparency background saving only the RGB wouldn't be enough.
cheers, On Thu, Dec 27, 2018 at 8:58 AM António Rodrigues Tomé <art...@gmail.com> wrote: > > > On Thu, Dec 27, 2018 at 2:38 AM Alan W. Irwin <alan.w.irwin1...@gmail.com> > wrote: > >> On 2018-12-27 01:04-0000 António Rodrigues Tomé wrote: >> >> > Hi Alan >> > you must revisit the -bg comand argument. >> [...] >> > P.s. >> > >> > may it be that the -bg argument is only called after the device >> constructor >> > has been valled? >> >> Nope, the -bg option works well normally. But you were right I had to >> revisit that option because in this case I screwed up the format of >> that option. Sorry about that! >> >> Note to self: add a warning message from the -bg option if >> a background colour is specified using a bad format (such as forgetting >> the underscore between RGB colours and alpha value like I just did). >> >> Here is an example with the correct -bg format >> >> examples/c/x30c -dev pngqt -o test3_qt.png -fam -bg 00F_0.3 >> >> (note the underscore in the -bg option!). This works properly with your >> revised code and produces a "fake" checkerboard background for both >> "display" and "pqiv" image viewer applications indicating both >> applications >> detected a semi-transparent background. Note also the size of the >> checkerboard blocks in the two cases is different confirming those are >> different artifacts added by these two applications (i.e., not >> something added by the PLplot code or Qt library). >> >> I have attached test3_qt.png.1 generated by the above command for >> your fixed case. Please let me know whether or not that gives >> the same results as your platform with whatever image viewer >> you are using to view that file. >> >> I also confirmed that I don't get the checkerboards for the two >> image viewing apps if I run >> >> examples/c/x30c -dev pngqt -o test4_qt.png -fam -bg 00F_0.3 >> >> without your fix. >> >> So your code fix appears to be good, but only seems to affect the >> background >> for some reason. But for the commit message I still need your best >> speculation (or Qt documentation reference if you have that) as to >> *why* that is the case and also *why* the old version of the >> code appeared to work OK for background opaque colours without >> the extra call to the fill method that you have put in now. >> >> So to address these commit message issues please respond to my >> previous questions about why ARGB32 is necessary in order to get the >> background to work but RGB32 seems to be fine for our unmodified code >> for the other transparency rendering that occurs, in, e.g., example >> 30. And please also respond to my question about why you think that >> opaque backgrounds but not semi-transparent background worked before >> you added the extra call to the fill method. >> > > Hi Alan. > Let start by saying that my English sucks. I've never learn it when I was > young only latter on on life I've learned some english reading math and > physics text books. > So the option ARGB32 seemed logical but the reason I changed it was > because RGB32 did not work. > So let me just copy a text from a link I had send you earlier > > "...Think of fill with alpha as a merge operation and not a replace. I was > thinking of it as a replace and therefore I was replacing every pixel with > a fully transparent black. However, because fillRect is really a merge I > was merging a transparent pixel with the background effectively doing > nothing..." > > > so if you have already a background and fill with a alpha brush you are in > fact doing a merge operation and probably the result is the above layer > acted as if it was semi transparent . > > The problem is for the background you have to have something to merge if > you start a background with a color you never get a transparency. If you > merge with alpa=0 you get the original background. That's the reason for > completely set the background at the device constructor to transparent > before doing anything else. And if we are in fact doing merge operations > (only when alpha is involved) this will not interfere when one uses solid > colors. > > with your correct -bg option I get exactly what you got. Although files > binary differ but I attach a screenshot with your file side by side with my > > > cheers > > > > > >> >> The reason for putting this sort of detail in your commit messages, is >> it is really helpful if someone runs "git blame >> bindings/qt_gui/plqt.cpp" 10 years from now (by the way, you should >> run that command for yourself right now to see what it does), spots >> the commit associated with your change and then looks at the >> corresponding git log message to help figure out what was on your mind >> when you made the change you did. (I use that technique all the time >> now to figure out why previous code changes were done.) >> >> Of course, if you found the combination of changes that worked by >> simply trying some experiments, (i.e., you have no idea why this >> change works) then state that. But I expect this fix was based on >> something specific in your Qt knowledge so that is what I need from >> you. >> >> And to finish your part in getting this change pushed, please state >> whatever tests you ran (in sufficient detail that I could replicate >> those for myself) so I can append that information to the "Tested by:" >> paragraph for you. >> >> Alan >> __________________________ >> Alan W. Irwin >> >> Programming affiliations with the FreeEOS equation-of-state >> implementation for stellar interiors (freeeos.sf.net); the Time >> Ephemerides project (timeephem.sf.net); PLplot scientific plotting >> software package (plplot.sf.net); the libLASi project >> (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); >> and the Linux Brochure Project (lbproject.sf.net). >> __________________________ >> >> Linux-powered Science >> __________________________ > > > > -- > > António Rodrigues Tomé > Universidade da Beira Interior > Instituto D. Luís (lab associado) > email address: > art...@gmail.com > art...@ubi.pt > http://www.researcherid.com/rid/A-5681-2013 > > -- António Rodrigues Tomé Universidade da Beira Interior Instituto D. Luís (lab associado) email address: art...@gmail.com art...@ubi.pt http://www.researcherid.com/rid/A-5681-2013
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
