CHDKPTP - PC Remote Control Performance Analysis - page 10 - RAW Shooting and Processing

reyalp

14118

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #90 on: 08 / September / 2012, 16:19:18 »

Advertisements

Quote from: SticK on 08 / September / 2012, 09:32:47

This function is essential to be able to enact the whole shoot&download sequence in one command, and in that sense would replicate the basic functionality of RemoteCapture (which is necessary, not better or worse) as a standard feature of your firmware/software system. To me it's a question of best-of-both-worlds rather than a competitive posture.

As I've said, I know shoot and download is a desirable feature. It's been on my list of things to add since I started the project. Whether it exists or not in some other software is irrelevant to me.

Logged

Don't forget what the H stands for.

SticK

779

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #91 on: 08 / September / 2012, 17:06:38 »

Quote "Whether it exists or not in some other software is irrelevant to me."

Could I make an case for relevance? I won't wait for your answer.

When folks use a prior application, they get used to performance offered by the app, even without regard of whether the feature should be there or not. If, as in your case, you are making remote control app that is supposed offer similar objectives at the core performance level, then some features that "customers" have gotten used to in the prior app would find desirable in the replacement. In my past (coding) life I have developed several applications and the most difficult, in fact sometimes impossible, was to put myself in the customer's shoes.

Just a thought to consider.

Logged

SticK

779

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #92 on: 08 / September / 2012, 17:15:28 »

Partial function:

Code: [Select]

function myshoot(tv, av, sv, destdir)
  cli:execute('shoot -tv='..tv..' -av='..av..' -sv='..sv..'')
  cli:execute('mdl -fmatch=%.[JDC][PNR][G2]$ DCIM '..destdir..'')
  --cli:execute('rm -fmatch=%.[JDC][PNR][G2]$ -nodirs DCIM') 
end

Test:

> !myshoot(1/2,5.6,200,"C:\\")
A/DCIM/117CANON/CRW_0025.DNG->C:\117CANON/CRW_0025.DNG
A/DCIM/117CANON/IMG_0025.JPG->C:\117CANON/IMG_0025.JPG

Directory is created // in this case it is unwanted ... also CANONMSC\ directory is created unnecessarily and is empty.

Is there a way around this, just to get the pure files in C:\ without the directories?

« Last Edit: 08 / September / 2012, 17:21:51 by SticK »

Logged

reyalp

14118

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #93 on: 08 / September / 2012, 17:49:30 »

Quote from: SticK on 08 / September / 2012, 17:15:28

Directory is created // in this case it is unwanted

Not if you use DCIM as the source. This is a limitation of the current mdownload command. The entire filematching system was a quick and dirty hack and needs to be reworked at some point.

If you use the nnnCANON directory as the source in the download command, then it won't be created on the destination, but you have to know the name. Using lua (con:listdir, documented in chdku.lua), you could get the contents of the DCIM directory and then invoke download on each of the nnnCANON directories if you wanted.

Quote

... also CANONMSC\ directory is created unnecessarily and is empty.

For this, you can use the -nodirs option on mdownload. Of course, if you switch to using the individual nnnCANON directories, then this problem goes away.

Logged

Don't forget what the H stands for.

SticK

779

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #94 on: 08 / September / 2012, 18:06:57 »

Quote "If you use the nnnCANON directory as the source in the download command, then it won't be created on the destination, but you have to know the name. Using lua (con:listdir, documented in chdku.lua), you could get the contents of the DCIM directory and then invoke download on each of the nnnCANON directories if you wanted."

Yes, know the name. Canon "arbitrarily" changes sub-directory names on the fly, so that's the problem. So the download and erase would have to recurse the tree.

Quote "dirty hack and needs to be reworked at some point."

I suppose you are referring to the fact it doesn't recurse ??

Quote "Using lua (con:listdir, documented in chdku.lua)"

Beyond me at this stage -- I'd like to learn how to work with lua but the priority right now is to pass integration tests with the equipment. I'll see what I can do with what I have.

Logged

reyalp

14118

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #95 on: 08 / September / 2012, 19:02:00 »

Quote from: SticK on 08 / September / 2012, 18:06:57

I suppose you are referring to the fact it doesn't recurse ??

It recurses just fine. The problem is that mdownload takes source(s) names with no pattern allowed, plus a pattern to match. This makes the code simple because -fmatch is just a lua pattern and source is just a string, but means you can't do stuff like mdl A/DCIM/*CANON/*.* c:/ as you could in a typical shell environment.

The difficulty identifying the current Canon directory and filename is also why "download last shot" is not currently implemented. This information is available to the CHDK raw code (except some ports like S90), but it's not available in Lua.

Quote

Beyond me at this stage -- I'd like to learn how to work with lua but the priority right now is to pass integration tests with the equipment. I'll see what I can do with what I have.

Your choice, but if you are actually going to use chdkptp for your project, getting used to using the scripting system will pay off. It is really quite flexible and easy to work with (In my completely biased opinion). You can try stuff out interactively, and then build it into a script.

How does con:listdir work ? Try it:

Code: [Select]

con> !return con:listdir('A/DCIM')
={
 [1]="100CANON",
}

Ok, listdir returns an array of names. So all we need to do is loop over that and insert it in the command.

Code: [Select]

con 12> !destdir='c:/';dcim=con:listdir('A/DCIM');for i,dname in ipairs(dcim) do cli:print_status(cli:execute('mdl -pretend -fmatch=%.[JDC][PNR][G2]$ DCIM/'..dname..' '..destdir)) end
A/DCIM/100CANON/IMG_4062.JPG->c:/IMG_4062.JPG
A/DCIM/100CANON/IMG_4063.JPG->c:/IMG_4063.JPG
A/DCIM/100CANON/IMG_4064.JPG->c:/IMG_4064.JPG
A/DCIM/100CANON/IMG_4065.JPG->c:/IMG_4065.JPG
A/DCIM/100CANON/IMG_4072.JPG->c:/IMG_4072.JPG

OK, but this is too much to type every time, we want it a lua file, and we don't want the CANONMSC directory (my camera didn't have one). We also want and option to remove the files, some indication if there is an error. Since we are playing with delete, we probably want a pretend option to test it too.

extras/dcimdl.lua

Code: [Select]

function dcimdl(destdir,del,pretend) 
	if pretend then
		pretend = '-pretend '
	else
		pretend = ''
	end
	local dcim,err=con:listdir('A/DCIM')
	if not dcim then
		printf('error listing directory %s\n',tostring(err))
		return
	end
	for i,dname in ipairs(dcim) do
		if dname ~= 'CANONMSC' then
			cli:print_status(cli:execute('mdl '..pretend..' -fmatch=%.[JDC][PNR][G2]$ DCIM/'..dname..' '..destdir))
			if del then
				cli:print_status(cli:execute('rm '..pretend..' -nodirs -fmatch=%.[JDC][PNR][G2]$ DCIM/'..dname))
			end
		end
	end
end

now lets try it

Code: [Select]

con> !require'extras/dcimdl'
con> !dcimdl('d:/temp',true,true)
A/DCIM/100CANON/IMG_4062.JPG->d:/temp/IMG_4062.JPG
A/DCIM/100CANON/IMG_4063.JPG->d:/temp/IMG_4063.JPG
A/DCIM/100CANON/IMG_4064.JPG->d:/temp/IMG_4064.JPG
A/DCIM/100CANON/IMG_4065.JPG->d:/temp/IMG_4065.JPG
A/DCIM/100CANON/IMG_4072.JPG->d:/temp/IMG_4072.JPG
A/DCIM/100CANON/IMG_4062.JPG: OK
A/DCIM/100CANON/IMG_4063.JPG: OK
A/DCIM/100CANON/IMG_4064.JPG: OK
A/DCIM/100CANON/IMG_4065.JPG: OK
A/DCIM/100CANON/IMG_4072.JPG: OK

Wasn't that easy ?

Do this a few times and you'll be writing scripts in less time than it takes me to answer on the forum.

« Last Edit: 08 / September / 2012, 19:03:43 by reyalp »

Logged

Don't forget what the H stands for.

SticK

779

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #96 on: 08 / September / 2012, 23:43:17 »

Quote "Wasn't that easy ?"

? Hmmm ... how many months did you say you've been writing lua ? Compare that to my roughly 15 lines all told in the last couple of weeks. When I wanted to make friends with this language the first thing I looked up in the manual was this unusual syntax '..var..' and could not even find it. Patience perhaps, might be inversely proportional to age I am finding. The first program I wrote was on an IBM1630 32K magcore one-room with punch card readers and may have possibly reached my limit too. So have some mercy... I'd be a monkey's uncle first before being able to generate the code you gave me by tomorrow evening. What *I* really need to start with is ... Lua for Dummies, if it exists.

Quote "getting used to using the scripting system will pay off. It is really quite flexible and easy to work with (In my completely biased opinion)"

You have me convinced hands down. Here's the scoop ..... the next critical level acceptance requires that everything (S90+CHDK+CHDKPTP) work without mutual interference in the instrumentation environment. To test that I do need the single call that does everything (ie shoot & transfer) and it does not have to be elegant or generic // it just has to work. If for example I get an unforeseen interaction among other applications I have running with CHDKPTP+ that prevents proper functionality in the environment, then I would not be able to even think about getting at the CCD // end of the road. While on the other hand, if everything works smoothly and I get a pass, then surely yes learning lua will definitely pay off.

So in short .... thanks for crafting out the piece.

Is there a script debugger you use that can help me step through code? A lua editor too?

Logged

waterwingz

12140

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #97 on: 09 / September / 2012, 00:21:35 »

Quote from: SticK on 08 / September / 2012, 23:43:17

What *I* really need to start with is ... Lua for Dummies, if it exists.

http://lua.gts-stolberg.de/en/index.php

Logged

Ported : A1200 SD940 G10 Powershot N G16

reyalp

14118

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #98 on: 09 / September / 2012, 01:09:47 »

Quote from: SticK on 08 / September / 2012, 23:43:17

When I wanted to make friends with this language the first thing I looked up in the manual was this unusual syntax '..var..' and could not even find it.

concatenation http://www.lua.org/manual/5.1/manual.html#2.5.4

Quote

What *I* really need to start with is ... Lua for Dummies, if it exists.

There are lots of general Lua tutorials online. There is also the book "programming in Lua" by the authors of the language. Assuming you are already a proficient programmer in some language, the reference manual http://www.lua.org/manual/5.1/ is pretty complete.

Quote

To test that I do need the single call that does everything (ie shoot & transfer) and it does not have to be elegant or generic // it just has to work.

chdkptp does not currently do this. Some future version might, but I work on it in my limited spare time, so there's no schedule. You should be able to do what you want with some additional programming. If that is not something you are prepared to do, then chdk and chdkptp may not be the right solution for you.

I'm willing try to help you understand what you need to now to do what you want, but I'm not interested in writing one-off hacks just to move your project forward.

Quote

Is there a script debugger you use that can help me step through code? A lua editor too?

There is no debugger built into chdkptp. However, it will give you a stack trace if there is a runtime error, and you can use print to display state. I tend to test small bits of code interactively in the console.

There are some generic debuggers for Lua code, but they will not include chdkptp APIs so you can't use them directly to develop chdkptp code.

No special editor is needed. If you want syntax highlighting, I expect most modern code editors have Lua support. Personally, I use vim.

Logged

Don't forget what the H stands for.

SticK

779

Re: CHDKPTP - PC Remote Control Performance Analysis

« Reply #99 on: 09 / September / 2012, 10:36:58 »

@waterwingz
You always come through with right thing at the right moment, so this sure helped. Trying to edit noobie lua code in Notepad is quite a chore. I found this editor in link you provided:
http://luaedit.luaforge.net/
... which at least colorizes the reserved words. For example, I just loaded in cli.lua and functionality jumped right out of the screen at me // nice // first chasm leaped over, thanks.

@reyalp
Quote "concatenation http://www.lua.org/manual/5.1/manual.html#2.5.4"

That's what I read at first and was no better off // examples I found are very poor in the manual. What actually helped though was your code because now I can translate the code reality back into the abstract requirements giving me the a reasonable starting point to work the normal direction.

Quote "Some future version might, but I work on it in my limited spare time, so there's no schedule. You should be able to do what you want with some additional programming"

That, is very comforting to know. Ideally, you would not use the SD card as a file buffer. How you'd transparently transfer the Canon files I think would be a major challenge w/o Canon writing to disk. For example the S90 has both JPEG and Canon compressed CR2 (7MB instead of 16MB CHDK) for significantly faster direct transfer. For now I will assemble a crude single call with what you've provided so I can execute the next series of acceptance tests, which has top priority ... because I don't know yet if everything will work properly in the instrumentation environment.

Quote "If that is not something you are prepared to do, then chdk and chdkptp may not be the right solution for you."

I recall mentioning some time ago your solution had great potential for my project. I can say now it has even greater potential ... I'm still around for very good reasons ... so ... I am proposing we take advantage of each others' different expertise areas for mutual benefit.

Quote "I'm not interested in writing one-off hacks just to move your project forward."

Mmm .. that hurts // I feel even more guilty for asking functionality from you so I will try to express what I've explored earlier in another way. Would you consider the piece you wrote a one-off hack exclusively for me and not something you could have basically ready to implement in a future version you talk about, or even include it in your standard distribution for folks to use right away? That is something honestly I am uncertain about. Perhaps it is the case. I present my feature requests within the context of the community and my perception of standard functionality, I hope ... do these requests (shoot, transfer, clean up chdkptp GUI, etc) not fit in?? Perhaps there is an eyes-of-the-beholder discrepancy between us. To illustrate the difference, here is one explicit example of what I consider I am not permitted to request of you. The spectrometric aperture is in the dead center of the visual field. Whenever I do a modification to the instrument, or just from aging, it has to go through realignment. It's a horrendous job, requiring shooting images, putting them into an editor, finding the aperture location and iterating the alignment settings. It can easily take a whole day. Do you see where I'm going? ... a reticle crosshair with a circle target in the center of the liveview with a user-defined size, black, white, XOR, with crosshair size settable independently of circle diameter // pushon // pushoff // and my instrument would be realigned in under an hour. That to me would be a personal request.

So as much as I'd love to have it especially that CHDKPTP is giving me a precision 640x480 liveview, the reality is I cannot ask for it. Do you see my point?

Logged