[Ssc-dev] It works!
Shawn Van Every
vanevery at walking-productions.com
Wed Jun 15 09:56:28 EDT 2011
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
More information about the Ssc-dev
mailing list