swapping channels then running forward causes score to change about larcv HOT 4 CLOSED

Hi Taritree I think I have a fix inplace -- in addition I think I have provided a way to provide a set of "preset" configuration button a la Janet's request (if you agree with the changes I would encourage you to point her to the most current iteration of the viewer)

A made a number of changes

• PlotImage is a generic EventImage2D loader
• work_mat now contains whatever is in self.img_v upon object creation
• because of a pyqt quirk the image gets displayed upside down therefore I by default do work_mat[:,::-1,:] and orig_mat[:,::-1,:] so that it displays the correct way on the screen
• before caffe is called I run self.revert_image() to flip it back
• what goes into caffe is now a copy of work_mat, for the 12 channel image this means I went in and did your transpose operation (I hope I implemented correctly) in the abstract method __caffe_copy_image__. If you open up ch12image.py on line 41 you will see I make a copy, then transpose it for caffe. This function is called in line 161 of plotimage.py in the emplace_image() definition on line 155. In this function I store the orig_mat in the work_mat, then make the copy for caffe (which includes transpose operation) then send this to TestWrapper

from larcv.

I don't have a pull request ready for you at the moment but I encourage you to checkout rgb_caffemod and test it out the interface has changed a bit.

I also forgot to mention that the switching channels has been resolved. I'm not an expert in the 12 channel image so please ensure that in caffe_copy_image that it's transposed correctly, work_mat contains 12 nonzero channels, which is different than in your branch

from larcv.

I took a few minutes to verify things were going into the blob ok in the wrapper using your script, I hope I can save you the trouble of having to check this a second time! The transpose operation in ch12image.py here seems fine. I guess it goes into the caffe blob O.K. -- when I take a look at bnb_set1_ch12_supported.root entry number 6

and dump using your savez line I see

and when I dump the lmdb bnb_set1_supported.db

there looks to be 1 or 2(?) tick offset just flipping the images back and forth as you probably mentioned already. The charge scale looks different as well which I also see -- sum of ADC from lmdb and sum of ADC from root file is 10^3 factor different. The output of compare_data_blob.py you can find at this pastebin between the two. The lmdb and the bnb sample is probably just different, but at least it sits in the blob o.k.

I also took a look at test.root which I think you created from bnb_set1_supported.db using convert_lmdb2image2d. The rows/colums look flipped to me in the viewer but that's no big deal.

There is no tick offset between entry 6 and 0*7_00 in the lmdb and I can match the network scores in the viewer and your python test script.

So in summary transpose operation before caffe is not needed for test.root before it goes to the wrapper, but is for the bnb*supported.root. In addition, bnb*supported.root's adc values are higher. So I think i'll leave the current implementation as is, transpose before it goes to caffe. Also, sorry I snooped around your larbys directory ;). Hopefully I can put this to rest and push to master

from larcv.

I think this is a legacy feature so I would close this issue. But please re-open if appropriate!

from larcv.