CHDK PTP interface - page 98 - General Discussion and Assistance - CHDK Forum  

CHDK PTP interface

  • 1227 Replies
  • 371902 Views
Re: CHDK PTP interface
« Reply #970 on: 08 / June / 2013, 22:22:23 »
Advertisements
Seeing the turbulent changes in CHDK trunk, it makes me wonder whether it would have been a better idea to continue development on the stable 1.1 codebase.
Or it might be time to bump the revs?  The UI changes in 1.2.0 are probably enough to justify moving it to "stable" status,  retiring 1.1.0,  rewriting the user guide,  and putting the ptp stuff into a newly created 1.3.0?
Ported :   A1200    SD940   G10    Powershot N    G16

*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #971 on: 08 / June / 2013, 22:44:03 »
Seeing the turbulent changes in CHDK trunk, it makes me wonder whether it would have been a better idea to continue development on the stable 1.1 codebase.
Or it might be time to bump the revs?  The UI changes in 1.2.0 are probably enough to justify moving it to "stable" status,
Probably.
Quote
rewriting the user guide,
Badly needed, but  :blink:
Quote
putting the ptp stuff into a newly created 1.3.0?
Without restructuring the rc code, it will become the same pain to maintain.

*

Offline reyalp

  • ******
  • 13390
Re: CHDK PTP interface
« Reply #972 on: 08 / June / 2013, 22:55:35 »
- Remove functionality that is unneeded at this point: YUV. I was going to say DNG too, since the RAW/DNG code has always been file-centered, and I had to butcher an existing DNG function (done in January(?), many things have happened since) to make DNG available for rc.
I agree about YUV. It's a bit of a pity having done the work, but I don't see any real use for it, especially considering you can't get it full res.

I think DNG, or at least the DNG header is worthwhile. But this requires some changes to be usable on the client.

I also think that a subimage of raw is still worthwhile.

Quote
- Split every possible piece of rc related code into separate files - looks like choosing capt_seq.c for holding the additional code was a bad idea.
I was thinking about this today too. Putting filewrite in it's own C file would make sense, but then we need somewhere for the generic filewrite stuff.

edit:
this will probably also avoid the pool problem, though in the long run it would be better to update the compiler on the autobuild server to something more recent.
Quote
- The rc related variables may need reorganization.
Agree, there's some cleanup that could be done.
Quote
- Remove the usage of event procedures. It's AFAIK not needed for rc to work.
Agreed.

Quote
Client side:
The problem is, any advanced usage of Lua is beyond me, which prevents me from doing any useful work on CHDKPTP.
That's understood, I have been slow working on this, and some changes need to happen simultaneously on both sides.
Quote
Seeing the turbulent changes in CHDK trunk, it makes me wonder whether it would have been a better idea to continue development on the stable 1.1 codebase.
I don't think so, getting it into the trunk would have been an even bigger problem then. We might have been better trying to to keep updated with the trunk, but that also would have made the final merge horrendous.

Quote
I still think that this kind of remote capture support is much better than retrieving the most recently shot image from the card.
I agree. However, getting from the card is needed as a fallback unless we implement filewrite for every camera.
Don't forget what the H stands for.

*

Offline reyalp

  • ******
  • 13390
Re: CHDK PTP interface
« Reply #973 on: 09 / June / 2013, 02:49:44 »
I've removed the PT_ hooks along with the imagesavecomplete logic and YUV support. I've left some parts of this commented in case we want to use it later. I think the imagesavecomplete stuff and the PT hooks might be useful at some point in the future, but they don't need to be done to finish the remote capture stuff.

I also split the filewrite code into separate files. I have built all the affected cameras but only tested a540 and d10 of course.

Splitting the filewrite code into it's own file does appear to resolve the literal pool issues.
Don't forget what the H stands for.


Re: CHDK PTP interface
« Reply #974 on: 09 / June / 2013, 06:13:13 »
I still think that this kind of remote capture support is much better than retrieving the most recently shot image from the card.

Maybe so, and this is an interesting excercise for those who enjoy code development, but realistically what is the PTP feature actually being used for in real life (rather than day-dreaming) and what percentage of CHDK users would be inconvenienced if it did not exist ?

Just curious.

A beautiful Summers day in the UK, will try to 'film' butterflies if it cools down ......

Re: CHDK PTP interface
« Reply #975 on: 09 / June / 2013, 10:52:46 »
Maybe so, and this is an interesting excercise for those who enjoy code development, but realistically what is the PTP feature actually being used for in real life (rather than day-dreaming) and what percentage of CHDK users would be inconvenienced if it did not exist ?
I would argue that once you get past basic setup & configuration issues,  the next most popular requests on this forum relate to projects that need to be able to coordinate activities between a PC and the camera. So ptp support is a lot more than just an interesting coding concept - there is as strong interest and demand for the capability.   And as that capability will apparently not be available in any other hacks, that just leaves CHDK.

Ported :   A1200    SD940   G10    Powershot N    G16

Re: CHDK PTP interface
« Reply #976 on: 09 / June / 2013, 11:28:57 »
as that capability will apparently not be available in any other hacks, that just leaves CHDK.

Yes, there is that.
In future versions of SDM I will be removing Zebra, histogram and edge overlay just to make it 'leaner' and reduce work for myself.

I would also prefer to remove raw but will probaly leave it in place.


Re: CHDK PTP interface
« Reply #977 on: 09 / June / 2013, 15:03:40 »
Maybe so, and this is an interesting excercise for those who enjoy code development, but realistically what is the PTP feature actually being used for in real life (rather than day-dreaming) and what percentage of CHDK users would be inconvenienced if it did not exist ?
I would argue that once you get past basic setup & configuration issues,  the next most popular requests on this forum relate to projects that need to be able to coordinate activities between a PC and the camera. So ptp support is a lot more than just an interesting coding concept - there is as strong interest and demand for the capability.   And as that capability will apparently not be available in any other hacks, that just leaves CHDK.

That is pretty much how I do my shooting.  My cameras are in a rig and tethered to my netbook.  I use PTP for setting up the cameras, taking the shots, downloading and deleting images,...  I also use chdkptp to determine what the best camera settings are for each new setup.  I would certainly miss it if this functionality was removed.


*

Offline srsa_4c

  • ******
  • 4426
Re: CHDK PTP interface
« Reply #978 on: 09 / June / 2013, 15:06:44 »
I agree about YUV. It's a bit of a pity having done the work
Well, my assumption about it turned out to be not true - it's not available in every camera anyway. Seeing ML's progress with EDMACs, this may change one time in the future.

I've removed the PT_ hooks along with the imagesavecomplete logic and YUV support. I've left some parts of this commented in case we want to use it later. I think the imagesavecomplete stuff and the PT hooks might be useful at some point in the future, but they don't need to be done to finish the remote capture stuff.

I also split the filewrite code into separate files. I have built all the affected cameras but only tested a540 and d10 of course.
Thanks for doing all this work. My a470 also works, including dng.
Quote
Splitting the filewrite code into it's own file does appear to resolve the literal pool issues.
I think that too large contiguous blocks of naked asm functions cause this kind of error.

The code in filewrite.c and remotecap.c is still kind of messy. The most irritating part is the huge number of #ifdef's, but I have no idea how to get rid of those.

*

Offline nafraf

  • *****
  • 1308
Re: CHDK PTP interface
« Reply #979 on: 09 / June / 2013, 15:31:55 »
I also split the filewrite code into separate files. I have built all the affected cameras but only tested a540 and d10 of course.
I tested on a495(100f) and a810(100d), it works.

 

Related Topics