[Ssc-dev] It works!
Shawn Van Every
vanevery at walking-productions.com
Sun Jun 19 12:16:39 EDT 2011
Hi Andrew,
Glad that it finally worked!
For sharing, I think we want to send a small version of the entire image so I am not sure the best way to handle that in terms of your library. What do you think? saveTmpImage is where it gets saved so initially there won't be any data there.
I think we should be able to to the JPEG per region for the other operations without too much trouble. We'll have to make sure that the regions aren't too big that we hit memory issues on their creation though. Do they have to be the same size as the region in the full size image or can they be smaller?
Looking forward to it!
-shawn
On Jun 17, 2011, at 11:53 PM, Andrew Senior wrote:
> OK, I think I wasn't refreshing the whole project- does F5 only refresh what you have selected?
> Anyway fixed now, and
> now jpegredaction seems to work for both camera and stored pics. [Not sure if I have to apply it in other paths such as saveTmpImage - I haven't tried any sharing operations yet]
> I have checked it in in jpegredaction branch, which is now just obscurav1 iwith my new changes, albeit that I originally branched off master....
> I also have it removing Exif now, but haven't fixed the thumbnails, so they're unredacted.
>
> I'll fix the thumbnails, and then I think this could be ready for real testing. I'll also look into doing a pixellation redaction. and other methods.
> To do image overlay, I think I'd need a JPEG of the right dimensions for each region passed in separately.
>
> As I now finally have obscurav1 on my phone-
> it looks great, and works well. The only bug I noticed was that sometimes the handles are smaller than the highlighted region, and sometimes (when it's newly created?) they match the region corners.
>
> Andrew
>
> On Thu, Jun 16, 2011 at 10:44 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> I would probably delete it from Eclipse at this point and recreate the project in Eclipse.
>
>
> On Jun 16, 2011, at 10:33 PM, Andrew Senior wrote:
>
> > Thanks. I can't figure it out. I had 'cleaned' but not refreshed. I found that even after refresh, when I switched to open tabs it would tell me that the file had changed. I closed eclipse and restarted.
> >
> > Now it says it won't build because it can't read MediaHasher.java I wonder if I somehow didn't update the "master project file" (or some such thing, if there is one) so it still points to this removed file.)
> >
> > I did
> > git fetch origin obscurav1:obscurav1
> > git checkout obscurav1
> > to make, and then switch to, a new local branch based on the github obscurav1, or so I thought...
> >
> > Andrew
> >
> > On Thu, Jun 16, 2011 at 10:13 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > Nathan was doing some branch merging tonight. It looks like he pulled your code from master and put it in obscurav1.
> >
> > Nathan, is that accurate??
> >
> > obscurav1 should build though. Make sure you do a "refresh" and a "clean" in Eclipse. Might also need to make sure you are building with Java 1.6.
> >
> > -s
> >
> > On Jun 16, 2011, at 10:05 PM, Andrew Senior wrote:
> >
> > > Hmm, I figured out how to get that branch but it shows several build errors for me in ImageEditor.java Not sure if they're caused by me merging badly or if that's the checked-in code?
> > > It does look like obscurav1 has an updated version of my library though. Did you merge that in from master?
> > >
> > > Andrew
> > >
> > > On Wed, Jun 15, 2011 at 11:09 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > Hmmn.. Sorry for the confusion with the variables. You should probably be working from the obscurav1 branch rather than the master. It has the up to date code.
> > >
> > > I just checked in an edit to the ImageEditor class in the obscurav1 branch that includes a method to pull out the path (it is the same as below but it works in the branch):
> > > pullPathFromUri(originalImageUri)
> > >
> > > Let me know how it goes.
> > >
> > > -s
> > >
> > > On Jun 15, 2011, at 10:28 PM, Andrew Senior wrote:
> > >
> > > > Thanks. I tried that, but with an image from the camera, the path I get is null. It does work for an image chosen from the gallery.
> > > > AFAICT originalImageUri is only in CameraObscura.java (and I don't see how it's set there) so I used imageUri which is available in ImageEditor:
> > > >
> > > > I attach an image which shows an interesting effect if you open it in the gallery. You see the original and then the redacted version - the gallery must display the thumbnail first, which I don't yet redact, and then display the main image, which is redacted.
> > > >
> > > > Here's the latest code I have- it's the current branch in JpegRedaction branch.
> > > >
> > > > // Queries the contentResolver to pull out the path for the actual file.
> > > > public String pullPathFromUri(Uri originalImageUri) {
> > > > String originalImageFilePath = null;
> > > > String[] columnsToSelect = { MediaStore.Images.Media.DATA };
> > > > Cursor imageCursor = getContentResolver().query( originalImageUri, columnsToSelect, null, null, null );
> > > > if ( imageCursor != null && imageCursor.getCount() == 1 ) {
> > > > imageCursor.moveToFirst();
> > > > originalImageFilePath = imageCursor.getString(imageCursor.getColumnIndex(MediaStore.Images.Media.DATA));
> > > > }
> > > >
> > > > return originalImageFilePath;
> > > > }
> > > >
> > > >
> > > > private void saveImage() {
> > > > String src_filename = pullPathFromUri(imageUri);
> > > >
> > > > // Uri is savedImageUri which is global
> > > > if (savedImageUri == null) {
> > > > ContentValues cv = new ContentValues();
> > > > savedImageUri = getContentResolver().insert(
> > > > Media.EXTERNAL_CONTENT_URI, cv);
> > > > }
> > > > String dest_filename = pullPathFromUri(savedImageUri);//mdh.getFileNameFromUri(savedImageUri);
> > > > Log.v(LOGTAG,"src_filename :" + src_filename );
> > > > Log.v(LOGTAG,"dest_filename:" + dest_filename );
> > > >
> > > >
> > > >
> > > > On Wed, Jun 15, 2011 at 9:56 AM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > > Hi Andrew,
> > > >
> > > > Good deal. I look forward to checking out the branch.
> > > >
> > > > For now, here is a bit of clarification on the various Uri variables:
> > > >
> > > > originalImageUri is never null but takes different forms Uri.getPath works when it is a "file" Uri but I can't guaruntee that and when it is a newly taken image it probably isn't. The following *should* work for any Uri and probably what you should do before passing to your native code:
> > > >
> > > > // Queries the contentResolver to pull out the path for the actual file.
> > > > public String pullPathFromUri(Uri originalUri) {
> > > > String originalImageFilePath = null;
> > > > String[] columnsToSelect = { MediaStore.Images.Media.DATA };
> > > > Cursor imageCursor = getContentResolver().query( originalImageUri, columnsToSelect, null, null, null );
> > > > if ( imageCursor != null && imageCursor.getCount() == 1 ) {
> > > > imageCursor.moveToFirst();
> > > > originalImageFilePath = imageCursor.getString(imageCursor.getColumnIndex(MediaStore.Images.Media.DATA));
> > > > }
> > > >
> > > > return originalImageFilePath;
> > > > }
> > > >
> > > > Please let me know if it works for both cases.
> > > >
> > > > The savedImageUri is only valid after an image has been saved. It is probably where you should write the new/redacted image to but you'll have to instantiate it first:
> > > >
> > > > ContentValues cv = new ContentValues();
> > > > savedImageUri = getContentResolver().insert(
> > > > Media.EXTERNAL_CONTENT_URI, cv);
> > > >
> > > > This will place the images in the MediaStore so they show up in the gallery.
> > > >
> > > > Talk to you soon,
> > > > shawn
> > > >
> > > > On Jun 15, 2011, at 12:47 AM, Andrew Senior wrote:
> > > >
> > > > > I got a little further, and I could benefit from some help at this point, please.
> > > > > I created a branch jpegredaction: https://github.com/guardianproject/SecureSmartCam/tree/jpegredaction/jni
> > > > > This now passes a source and destination path into the library as well as constructing a string of the region coordinates.
> > > > > It looks like this works, for the case of the image being selected from media, but I don't know what to pass it if the photo is newly taken (I don't see an 'originalImageUri' variable). Similarly savedImageUri seems to be null for the image-from-media case, so this fails:
> > > > > dest_filename = mdh.getFileNameFromUri(savedImageUri);
> > > > >
> > > > > [Ah, if I do savedImageUri.getPath() ] it seems to work for newphotos, but fails for stored media- not sure how I tell which I have]
> > > > >
> > > > > Hopefully you can figure out what I should be doing and set me on the right track.
> > > > > Next would be to look into the following:
> > > > > 1) returning redacted information for encryption/storage
> > > > > 2) handling Exif
> > > > > 3) handling other redaction styles (e.g. average / fixed colour, pixellation, imageoverwrite).
> > > > >
> > > > > Andrew
> > > > >
> > > > > On Mon, Jun 13, 2011 at 3:04 AM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > > > Hi Andrew,
> > > > >
> > > > > Good deal.
> > > > >
> > > > > Yes, sorry, I was a bit sloppy with the initial check-in, leaving the .o files. They should probably be removed. I put everything in the same directory just to get it working in the first place. Again, I didn't go back and cleanup after I got it working.
> > > > >
> > > > > I agree. We should probably move all of this to a new branch and then remove it from the current obscurav1 branch. Do you want to create a new branch with your latest?
> > > > >
> > > > > With regards to the image sizes, yes, the full size image is available although not loaded into memory. The "originalImageUri" variable points to it. All of the current work is being done on new smaller version that contains none of the metadata of the original (no EXIF data is retained).
> > > > >
> > > > > The coordinates saved in ImageRegion are on based on the original unscaled image so if you use the ImageRegion.unscaledRect those coordinates should be what you are looking for.
> > > > >
> > > > > Thanks for jumping in on this!
> > > > >
> > > > > Talk soon,
> > > > > shawn
> > > > >
> > > > >
> > > > >
> > > > > On Jun 13, 2011, at 12:33 AM, Andrew Senior wrote:
> > > > >
> > > > > > Shawn,
> > > > > >
> > > > > > I made a bit more progress. I fixed a couple more bugs in my library and have my latest code doing a placeholder redaction on the selected image.
> > > > > >
> > > > > > Before I check in- 1) I see there are .o files checked in in the jni dir- can they be deleted. My NDK (the crystax version suggested for OpenCV building on android) made .o files and library in a different dir?
> > > > > > I was thinking I'd check in the latest C++ code in the jni dir, in the main branch, and then work in a different branch when I start actually hooking it up?
> > > > > >
> > > > > > I would need to understand the coordinates used to do the desired redaction- for both the stored-image and the newly-taken-photo, are the redaction regions stored in image coordinates of the preview image? (as opposed to the stored-image's true size?) When you take a new picture, is it currently taken at full size and you work on / redact a down-sampled preview, or is there never a full (e.g. 5MP) version?
> > > > > >
> > > > > > Is the default in the current app to delete all Exif data?
> > > > > >
> > > > > > Andrew
> > > > > >
> > > > > >
> > > > > > On Sun, Jun 12, 2011 at 12:31 AM, Andrew Senior <aws at andrewsenior.com> wrote:
> > > > > > Ah, I figured out the bug, which was I'd seen in a different form but failed to track down in my cygwin build.
> > > > > > I got it to work on Android, but will check in the code when I've got my unit tests straight and ironed out another issue this exposes with padding the final JPEG bitstream byte.
> > > > > >
> > > > > > Andrew
> > > > > >
> > > > > >
> > > > > > On Sat, Jun 11, 2011 at 11:49 PM, Andrew Senior <aws at andrewsenior.com> wrote:
> > > > > > Thanks.
> > > > > > I was able to follow those instructions, despite my tenuous handle on things-Androidy.
> > > > > > As you said... It worked!
> > > > > > However, when I tried my latest code it gave me a segmentation fault.
> > > > > > I'll have a look when I get a chance.
> > > > > > I'll have to do some Android logging from my code, and also work out how to pass the filename/URI into the C++ code.
> > > > > >
> > > > > > Andrew
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Fri, Jun 10, 2011 at 11:29 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > > > > Hi Andrew,
> > > > > >
> > > > > > I unfortunately haven't gotten a chance to get further than doing that initial build and test with your code. I put the code from the test in the project and included it in the obscurav1 version as we still intend to continue with it.
> > > > > >
> > > > > > To build the native code, you have to run the ndk-build script from the android NDK download in the project directory. It builds the native code which is in the JNI directory and uses the Android.mk and Application.mk scripts which are standard for the Android NDK.
> > > > > >
> > > > > > The org_witness_securesmartcam_jpegredaction_JpegRedaction.cpp and .h file contains the native implementation of the method in the JpegRedaction.java file.
> > > > > >
> > > > > > The (non-existant) hook would be in the ImageEditor.java in the saveImage method. It could instantiate JpegRedaction and call the redactit method.
> > > > > >
> > > > > > If you are up to taking a stab at incorporating it, let me know. We can create a branch of the release version and go from there.
> > > > > >
> > > > > > Sorry for being slow with progress on this portion.
> > > > > >
> > > > > > -s
> > > > > >
> > > > > >
> > > > > > On Jun 10, 2011, at 10:54 PM, Andrew Senior wrote:
> > > > > >
> > > > > > > Shawn,
> > > > > > >
> > > > > > > Can you give me a pointer as to how I could test JpegRedactionLibrary with obscura - I see the
> > > > > > > org.witness.securesmartcam.jpegredaction;
> > > > > > > item in the java, and my code, plus your wrapper under the jni directory.
> > > > > > > In the v1.0.1 there isn't any UI hook to call my code, I presume.
> > > > > > > How should I build the C++ code- when I clean the .o files don't disappear, so I presume I have to build it separately ?
> > > > > > >
> > > > > > > Andrew
> > > > > > >
> > > > > > > On Thu, Apr 21, 2011 at 1:40 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > > > > > Great! I'll checkout the latest version and give these examples a shot. I'll export the eclipse project and send it over so you can see how it is organized as well.
> > > > > > >
> > > > > > > Talk soon
> > > > > > > -- mobile shawn
> > > > > > >
> > > > > > >
> > > > > > > Andrew Senior <aws at andrewsenior.com> wrote:
> > > > > > > Also, I didn't point out that the latest version will return a set of "strips" in the redaction object. Those can be saved and used later for reversing the redaction. You can save them externally (e.g. in the database), or I can store them in the JPEG file somehow- either way they need to be encrypted. If they're being stored in the JPEG then I'll need a later call to pass in the encrypted info, or perhaps even better a callback [that I can call while redacting] so that I can write out the JPEG in one go.
> > > > > > >
> > > > > > > Later if you pass back the same data (after decryption) I should be able to reverse the redaction, but haven't yet got this bit working.
> > > > > > >
> > > > > > > Andrew
> > > > > > >
> > > > > > > PS Perhaps these code snippets will make it clearer what I'm trying to say.
> > > > > > >
> > > > > > > // Usage case 1: The encrypted redaction data is stored in the JPEG image somehow. Encryption is done with
> > > > > > > // a callback
> > > > > > > jpeg_redaction::Jpeg j2("/sdcard/windows.jpg", true);
> > > > > > > jpeg_redaction::Redaction::Rect rect(50, 600, 50, 600);
> > > > > > > jpeg_redaction::Redaction redaction;
> > > > > > > redaction.AddRegion(rect);
> > > > > > > EncryptionCallback the_encryption_callback(key)
> > > > > > > j2.ParseImage(redaction, the_encryption_callback);
> > > > > > > j2.Save("/sdcard/testoutput_with_redaction_data.jpg");
> > > > > > > ....
> > > > > > > // Now restore the image
> > > > > > > jpeg_redaction::Jpeg j2("/sdcard/testoutput_with_redaction_data.jpg", true);
> > > > > > > DecryptionCallback the_decryption_callback(key)
> > > > > > > j2.ReverseRedaction(the_decryption_callback);
> > > > > > > j2.Save("/sdcard/unredacted.jpg");
> > > > > > >
> > > > > > > // Usage case 2: data is stored in the database.
> > > > > > > jpeg_redaction::Jpeg j2("/sdcard/windows.jpg", true);
> > > > > > > jpeg_redaction::Redaction::Rect rect(50, 600, 50, 600);
> > > > > > > jpeg_redaction::Redaction redaction;
> > > > > > > redaction.AddRegion(rect);
> > > > > > > j2.ParseImage(redaction);
> > > > > > > j2.Save("/sdcard/testoutput.jpg");
> > > > > > > database.SaveRedactionDataAfterEncryption(the_database_key, redaction)
> > > > > > >
> > > > > > > // Now restore the image
> > > > > > > jpeg_redaction::Jpeg j2("/sdcard/testoutput.jpg", true);
> > > > > > > jpeg_redaction::Redaction redaction;
> > > > > > > database.RetrieveRedactionDataAndDecrypt(the_database_key, redaction)
> > > > > > > j2.ReverseRedaction(redaction);
> > > > > > > j2.Save("/sdcard/unredacted.jpg");
> > > > > > >
> > > > > > > On Wed, Apr 20, 2011 at 5:19 PM, Andrew Senior <aws at andrewsenior.com> wrote:
> > > > > > > Hey, that's great. That looks like a sensible sequence.
> > > > > > >
> > > > > > > The "rawgrey.pgm" is really a debugging thing- it returns the image that I get by decoding the intensity DC coefficients of each block, so ignoring colour, and giving an 8x8 downsampling.
> > > > > > > You should be able to supply NULL to that parameter and it will be ignored.
> > > > > > > However, since you're using "ParseImage", you're not using the latest version of the repository (now DecodeImage IIRC), so perhaps I didn't fix that check-for-null.
> > > > > > > In practice it doesn't make sense to have this debugging parameter in there, so I'll get rid of it.
> > > > > > > Let me know what things needed shifting around, and we can work out what the best way is, especially as I've checked in some changes since. Let me know your github ID and you can have write access.
> > > > > > > Andrew
> > > > > > >
> > > > > > >
> > > > > > > On Wed, Apr 20, 2011 at 12:56 PM, Shawn Van Every <vanevery at walking-productions.com> wrote:
> > > > > > > Andrew,
> > > > > > >
> > > > > > > I was able to get a simple example using your library working on Android!
> > > > > > >
> > > > > > > Here is what I am running:
> > > > > > >
> > > > > > > jpeg_redaction::Jpeg j2("/sdcard/windows.jpg", true);
> > > > > > > jpeg_redaction::Redaction::Rect rect(50, 600, 50, 600);
> > > > > > > jpeg_redaction::Redaction redaction;
> > > > > > > redaction.AddRegion(rect);
> > > > > > > j2.ParseImage(redaction, "/sdcard/rawgrey.pgm");
> > > > > > > j2.Save("/sdcard/testoutput.jpg");
> > > > > > >
> > > > > > > Does this make sense?
> > > > > > >
> > > > > > > Specifically, I am wondering what the rawgrey.pgm file is for in the ParseImage function.
> > > > > > >
> > > > > > > I had to do a bit a of moving things around to get it all to compile correctly for use on Android with the NDK so I am wondering if I should create another repo somewhere to house this or if we can check it in to your github repo?
> > > > > > >
> > > > > > > -s
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > >
> > > > > > Shawn Van Every
> > > > > > vanevery at walking-productions.com
> > > > > > Mobile and Streaming Consulting
> > > > > > http://www.walking-productions.com/notslop
> > > > > > Author: Pro Android Media: http://amzn.to/eYb48C
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > > > Shawn Van Every
> > > > > vanevery at walking-productions.com
> > > > > Mobile and Streaming Consulting
> > > > > http://www.walking-productions.com/notslop
> > > > > Author: Pro Android Media: http://amzn.to/eYb48C
> > > > >
> > > > >
> > > >
> > > > Shawn Van Every
> > > > vanevery at walking-productions.com
> > > > Mobile and Streaming Consulting
> > > > http://www.walking-productions.com/notslop
> > > > Author: Pro Android Media: http://amzn.to/eYb48C
> > > >
> > > >
> > > > <1308188676325.jpg>
> > >
> > > Shawn Van Every
> > > vanevery at walking-productions.com
> > > Mobile and Streaming Consulting
> > > http://www.walking-productions.com/notslop
> > > Author: Pro Android Media: http://amzn.to/eYb48C
> > >
> > >
> >
> > Shawn Van Every
> > vanevery at walking-productions.com
> > Mobile and Streaming Consulting
> > http://www.walking-productions.com/notslop
> > Author: Pro Android Media: http://amzn.to/eYb48C
> >
> >
>
> Shawn Van Every
> vanevery at walking-productions.com
> Mobile and Streaming Consulting
> http://www.walking-productions.com/notslop
> Author: Pro Android Media: http://amzn.to/eYb48C
>
>
Shawn Van Every
vanevery at walking-productions.com
Mobile and Streaming Consulting
http://www.walking-productions.com/notslop
Author: Pro Android Media: http://amzn.to/eYb48C
More information about the Ssc-dev
mailing list