Can SUCR be Updated to work with libusb 1.10.1? I finally got my CVS videocam working well, but had to update to libusb1.10.1 to do so. Unfortunately, the old SUCR 0.5 program does not "find" the camera anymore, even with various configs for the device drivers.
Can anyone update teh SUCR program to work with libusb 1.10.1? Seems a shame to not be able to use the old Ritz Dakotas anymore.
radarman- 08-05-2005
Why did you have to update? I'm using both the CVS PV2 and camcorder with libusb 1.8?
I'd downgrade if I were you.
chiusano- 08-05-2005
I had to update because the libusb0.sys for 1.8.0 would not function properly, and win XP media center would not properly recognize the device. (it woudl see it, but not allow any interfacing)
dfink- 08-09-2005
Once you have your video camera working with libusb 1.10.1 try unistalling it and intall libusb 1.8. Use the saturn program thats matched with that version of libusb(1.8) to download your videos. It might work, it might not, but it worked for me.
chiusano- 08-10-2005
I tried the unistall of 1.10.1 and reinstall of 1.8, but the old problems witht hXP not completely working with the drivers returned, so I am sticking with 1.10.1
It woudl be cool if SUCR would be redeveloped for 1.10.1, or even better yet if the SUCR, PV2 an OPS programs could be merged.
brite_eye- 08-10-2005
I doubt BillW has the time to spare - or anyone else. But I'd be willing to pay a couple of dollars for a merged set of software and probably several others would also. That probably doesn't work well with all the GPLs but given a significant financial incentive someone might take on the task.
catastrophe- 08-10-2005
RE: sourceforge donations!? I doubt BillW has the time to spare - or anyone else. But I'd be willing to pay a couple of dollars for a merged set of software and probably several others would also. That probably doesn't work well with all the GPLs but given a significant financial incentive someone might take on the task.
Seems like a "sourceforge PV2DevKit Project donation" is in order? :twisted:
(Wish there was a forum for the Dakota Digital and SUCR... for completeness I suppose)
Drmn4ea- 08-11-2005
It's a good idea; I originally intended SUCR to handle "all single-use cameras" (back when there were only Dakota Classic and the little-known Walgreens Cam), but have not gotten enough free time to try and merge in anything from the PV2 and camcorder...complicating things especially at the time was that the PV2 tools were being updated about weekly, sort of how the camcorder tools are right now in rapid development, and porting in the new versions each time would have been non-trivial.
Hopefully once my work/travel schedule dies down after summer, I'll implement a single-click download functionality similar to how it exists for the Classic., and make sure it will build with the la-*test*-('") and grea-*test*-('") libusb version. This effort will focus on doing one thing and doing it well (downloading and postprocessing pictures to look good with minimum effort) - bonus features like running your own code on the camera I'll worry about later (if at all). Processing effort will focus on profile-based forumer.com/viewtopic.php?t=407>imager noise reduction, dead pixel detection/correction, followed by anything 'destructive' the user wants after debayer - color/gamma/WB correction, sharpening, histogram remapping...
BillW- 08-11-2005
Drmn4ea, if you set up the framework and carve out a rough idea of the internal API you'd be using for each cam, I'd be willing to port stuff over from pv2tool and ops.
Just a thought. If you want to DIY, I'd understand too. (easily done, thanks to the open/free licensing of our tools)
Drmn4ea- 08-14-2005
Cool! I'm not sure exactly how to go about specifying an API though...really I'm more of a hardware guy :-)
What I want basically to do is wrap the PV2 image downloading and erasing (PV2tool), decompression (pv2raw) and post-processing (RAWGL) into the same program. But after that, wrap all that + the Dakota Classic downloading + camcorder video downloading into the same program, so that it actually lives up to its name (Single-Use Camera Reader)
I guess what it comes down to is, what is the easiest way to wrap it all together without throwing away all the hard work everyone's already put in?
BillW- 08-14-2005
I guess it kind of depends how you're going to construct the GUI. If it's going to be "Sucr for all CVS devices", here's a rough guess at the type of backend functions you'll want for each device:
UnlockCamera()
DownloadAllPictures()
GetPictureCount()
ErasePictures()
For now I'd suggest you keep it simple and just have a case statement and call the appropriate version of each function when the buttons are pushed. (eg. If a saturn was enumerated/selected, than call SaturnUnlockCamera())
I'm also thinking that the pv2 version of DownloadAllPictures would be responsible for calling it's own image format conversion routines, since post-processing isn't required on the other devices. As a sidenote, it might be nice if the app left the pv2 RAWs in the download directory too.
If you leave in stub functions for the Saturn and PV2 devices, and just fill out the dakota ones, I can fill them pretty quickly with my mastery of cut'n'paste coding! ;)
Soneone else would hopefully lend a hand with the actual RAW->PNG conversion porting (daBass, you interested?)
BTW, you're more of a software guy than some of the people I know that profess to be software guys. :P
Drmn4ea- 08-15-2005
That would make things super easy; it sounds like those would cover all the important stuff. It might be easier(?) to have the download function return 1 picture at a time, based on the count from GetPictureCount(), e.g. image=downloadPicture(number); ...25+ files sounds like a lot to pass around in memory at once between functions.
One other "nice to have" would be a function to download firmware (overload the same GUI function from DakotaClassic), but isn't truly necessary - if someone's interested in downloading F/W, they're probably interested in patching, uploading, running their own code and other advanced features, and PV2tool is already ideal for this stuff :-)
I don't think there is any easy way to get/set the PV2's Flash ID#, but if it's possible for someone (or me) to hack together something, it would be very helpful in tying FPN/dead-pixel profiles to specific cameras.
SUCR will detect and connect to the device on load (or Re-Query?), so there will already be a USB device handle, and the endpoints for the detected device will be known. I'll put a case statement inside the major GUI functions, hopefully things won't get too messy.
PV2 is a bit of a special case because of all the postprocessing that will be done; I'm with you that it will be easiest to do all the postprocessing, including ->PNG conversion, inside the main Download...() loop. My goal in the image-processing part for PV2 will be to move as much processing as possible to before the debayer step, so I'd probably have a simple 'raw2cfa' function that incorporates the pv2raw* decompression, some processing functions called in sequence that the CFA image is hot-potatoed through, e.g.
image=raw2cfa(raw_image);
image=deadpix(denoise(image)); /* operations that should be done at the CFA step */
image=debayer_by_some_method(image);
image=gamma(image, r, g, b); /* and all the other stuff that can be done post-debayer */
...
(ideally, the actual set/sequence of filters will be user-selectable and stored in an .ini file. But a standardized format for filters will be nice since then anyone can write new filters and they can be added more-or-less just by #include-ing their file.)
And like you said, if someone else is able/willing to take on the dirty work of a 'raw2cfa' and 'pixmap2png', that will make things a lot faster :-)
Create987- 08-15-2005
I'm also thinking that the pv2 version of DownloadAllPictures would be responsible for calling it's own image format conversion routines, since post-processing isn't required on the other devices. As a sidenote, it might be nice if the app left the pv2 RAWs in the download directory too.
If you leave in stub functions for the Saturn and PV2 devices, and just fill out the dakota ones, I can fill them pretty quickly with my mastery of cut'n'paste coding! ;)
Soneone else would hopefully lend a hand with the actual RAW->PNG conversion porting (daBass, you interested?)
Actually, I'm pretty far down the path of doing just that. I was warming over your tool to save both the .RAW files and convert them to .PNG using the algorithms in SailPix's post processor.
I deliberately made added the code with hardly any changes to your code to make it easy to fold back in to the code base if you like the changes. I suspect we don't want multiple versions of the tool floating around.
But, I put it on hold for a little bit. I'm thinking a better solution would be to warm over the camera firmware to save either .BMP, .JPG or .PNG files and then make it mountable as a removable drive like most other digital cameras behave.
Your thoughts???
BillW- 08-15-2005
...It might be easier(?) to have the download function return 1 picture at a time, based on the count from GetPictureCount()...
The only problem with that is the camcorder. Currently we can't delete one at a time. (we do a format to actually erase the movies)
Can the design be based around a mass erase at the end?
I don't think there is any easy way to get/set the PV2's Flash ID#, but if it's possible for someone (or me) to hack together something, it would be very helpful in tying FPN/dead-pixel profiles to specific cameras.
Actually, that one's pretty easy - in the last "updates for morcheeba's pages" I documented that one of the partially understood commands was actually a "read field from nvram.dat" command. The nerve pinch data comes directly from nvram.dat.
The only problem I see with your idea is that reset cameras will all look identical.
The dead pixel idea is awsome. Thought about storing the data on the camera itself? If you stored it in a file called MENU.TFT, the camera will even preserve it during formats. (though it will put a randomish background behind the nerve pinch screen)
It would also be neat to add color calibration data to that too, like the camcalib.dat file that most people lost. Perhaps in version 2.0... ;)
Create987, cool work! I'd definitely accept the finished code into pv2tool, or if you wanted to fork it I'd even provide hosting at the sourceforge site. Personally I think the choice in programs provided by a fork is a good thing.
Regarding mass storage and saving in other formats, I'd love to see it, but I think those days are still far off.
Create987- 08-15-2005
Create987, cool work! I'd definitely accept the finished code into pv2tool, or if you wanted to fork it I'd even provide hosting at the sourceforge site. Personally I think the choice in programs provided by a fork is a good thing.
Regarding mass storage and saving in other formats, I'd love to see it, but I think those days are still far off.
Personally, I think the community would be better served by not forking the code bases yet. A few check boxes to specify wheather to save the .RAW's and perhaps eventually which format (.JPG, .BMP or .PNG) would be of the most value to people. The problem is you are making changes too fast, so forking the code base causes people to run one utility for this and some other program for that. It would be better to have everything in one place for a while.
As far as 'removable media' and other formats on the camera, I don't think they are that far off. Once the firmware is rebuildable, I'm going to dig in. Neither of those should be that nasty. But getting a dump of the bootloader firmware would answer a lot of questions and make things a lot easier.
Forumer™ is Voted #1 Free Forum Hosting provider
Build your own community today with the largest message board hosting company.
