CHDK PTP interface - page 93 - General Discussion and Assistance - CHDK Forum supplierdeeply
« previous next »
Pages: 1 ... 88 89 90 91 92 [93] 94 95 96 97 98 ... 125   Go Down

CHDK PTP interface

  • 1241 Replies
  • 487963 Views
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #920 on: 30 / December / 2012, 19:30:46 »
Advertisements
Quote from: srsa_4c on 29 / December / 2012, 13:26:29
Thanks for that, I wanted to use Nparam for an additional check, not sure whether it will still be needed when the protocol becomes final.
Yeah, I'm not sure varying the number of return parameters is a great idea, but it seemed like something the PTP code should provide.

Quote
I'm considering the simplification of filewrite_main_hook()'s arguments. If the FileWriteTask data block is mapped to a camera-specific structure, only a pointer would be needed as a single argument. It would also make the assembly (glue) part simpler and the code less ugly.
Reducing the amount of glue sounds good.

A question about fwt_open etc. Is there a reason these can't be C code? Since they are called as a replacement for a normal function call, it seems like you should just be able to make normal C function with the appropriate number of parameters. The registers will be preserved or not according to the ARM ABI, just like the replaced call.

eg:
Code: [Select]
int fwt_open(char *name,int  flags,int mode) {
 if(ignore_current_write) {
  current_write_ignored = ignore_current_write;
  return 0xff;
 }
 return _Open(name,flags,mode);
}
not promising I understood the current asm correctly... which is a good reason to do it in C

Some more general thoughts, (thinking out loud, not saying anything has to change)
YUV:
Is this really worth the effort? What situations would the jpeg not be good enough, but the raw too much much? I know it is relatively easy to get, but it's still several functions that have to be added to each lib.c and then it isn't available in all shooting modes. I guess the YUV may be nice because some third party libraries would already be able to deal with it directly, with even less overhead than jpeg. I'm not against including it, just wondering if there is a specific use that makes it important.

DNG:
For applications that want to maximize speed, it would be useful to be able to get the DNG header without having the DNG data bytes reversed. This could also provide a way for dealing with reduced cropped images. You would get the full header (with the dimensions set normally) and the client application could reverse the bytes and pad it to the desired size, or adjust the dng dimensions.

Getting a fully ready to use DNG is still convenient, so I think that capability should be preserved even if we make non-reversed available.

I'm not sure I like relying the chdk UI DNG setting to decide if raw returns plain raw or DNG, especially since you have to use set_config_value / get_config_value to modify it from script. It seems like the client should explicitly ask for what it wants.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #921 on: 30 / December / 2012, 20:42:39 »
Quote from: reyalp on 30 / December / 2012, 19:30:46
Reducing the amount of glue sounds good.

A question about fwt_open etc. Is there a reason these can't be C code? Since they are called as a replacement for a normal function call, it seems like you should just be able to make normal C function with the appropriate number of parameters. The registers will be preserved or not according to the ARM ABI, just like the replaced call.

eg:
Code: [Select]
int fwt_open(char *name,int  flags,int mode) {
 if(ignore_current_write) {
  current_write_ignored = ignore_current_write;
  return 0xff;
 }
 return _Open(name,flags,mode);
}
not promising I understood the current asm correctly... which is a good reason to do it in C
You're probably right. Those functions started out as part of the "glue" and I wanted full control over the saved registers, so I haven't even thought about doing them in C :)
I don't know how the compiler decides over which registers should be preserved. If you think it's safe to do, then I'll re-write them.
Quote
Some more general thoughts, (thinking out loud, not saying anything has to change)
YUV:
Is this really worth the effort? What situations would the jpeg not be good enough, but the raw too much much? I know it is relatively easy to get, but it's still several functions that have to be added to each lib.c and then it isn't available in all shooting modes. I guess the YUV may be nice because some third party libraries would already be able to deal with it directly, with even less overhead than jpeg. I'm not against including it, just wondering if there is a specific use that makes it important.
Well, this part is a bit neglected at the moment, with only one of the cameras supporting it. It's true that it's of no use to most of the expected user base (which may not be very high either), and getting the YUV is a bit troublesome (it's not present when the JPEG is L or W sized, needs activated review to not get erased before transfer). I thought it would be interesting to have it, because 1) you get to see which part of the image deterioration is the result of the camera's JPEG compression 2) if you'd like to pre-process the image somehow (say, you want some text or image overlay on it) before storing or using it, you evidently lose quality when your source is already JPEG compressed 3) it might be good sometimes that the camera is doing demosaicing for you (sadly excluding full size).
Cons: 1) takes some space in memory 2) many things to watch out for before getting it 3) might be non-trivial to do on a new port 4) some disappointed users in case it's not implemented for a port
Quote
DNG:
For applications that want to maximize speed, it would be useful to be able to get the DNG header without having the DNG data bytes reversed.
Yes, the current code is the first try (I think there are comments indicating this possibility)
Quote
This could also provide a way for dealing with reduced cropped images. You would get the full header (with the dimensions set normally) and the client application could reverse the bytes and pad it to the desired size, or adjust the dng dimensions.
I probably wanted to avoid dealing with both sides of this, to keep the first implementation simple and not having to code more :)

Quote
I'm not sure I like relying the chdk UI DNG setting to decide if raw returns plain raw or DNG, especially since you have to use set_config_value / get_config_value to modify it from script. It seems like the client should explicitly ask for what it wants.
No objections, I did it so, because it seemed easy for a shooting script to include set_config_value. Should this be handled by a new script command setting some static variables, or ...?
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #922 on: 30 / December / 2012, 21:23:56 »
Quote from: srsa_4c on 30 / December / 2012, 20:42:39
I don't know how the compiler decides over which registers should be preserved. If you think it's safe to do, then I'll re-write them.
In general if you are replacing a canon firmware function call with another function call, it should be safe. Which registers are preserved is defined by the ABI, the compiler doesn't look at the called/calling code (it can't since they could be in different object files.) The ARM function call ABI is pretty standard (+/- different floating point modes and arm/thumb interworking) unlike the PC world where different compilers have used wildly different conventions.

Quote
I probably wanted to avoid dealing with both sides of this, to keep the first implementation simple and not having to code more :)
Understood, and agreed that it's better to get something simple working first :)

Quote
No objections, I did it so, because it seemed easy for a shooting script to include set_config_value.
Yes I see the attraction of this. It's not clear how this would work if we wanted to allow the DNG header separately or byte reversing control though.
Quote
Should this be handled by a new script command setting some static variables, or ...?
I would expect it to be part of init_remotecap. Logically I'd expect it to just be a format option, but having raw and dng be separate bitflags doesn't really make sense.

Thinking out loud, maybe format bits should be something like
jpeg, yuv, raw, dng header, raw byte order

dng header without raw might be useful, for example if you wanted to turn yuv into some sort of file with exif-like data. Raw byte order wouldn't really make sense if raw was disabled, but it could just be ignored.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #923 on: 31 / December / 2012, 00:55:00 »
I added YUV support for a540. As expected, it does not work in wide or large modes.

I didn't find a program that would convert the YUV data to nice looking image, but yuv2pnm from netpbm does good enough to verify that the data is valid and dimensions are correct. Loading the yuv data into gimp as raw RGB565 produces amusing results ;)
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #924 on: 01 / January / 2013, 15:41:58 »
Added FileWriteHook for D10. No YUV, not sure if it exists on digic > 2, or how to find it.

I also wasn't clear how MAX_CHUNKS_FOR_JPEG is determined. 3 seems to work. I assume the structure is OK, since I get a valid jpeg.

@srsa
I was thinking about removing the all in one "remoteshoot" command and associated functions from chdkptp, so we only have to keep the lua based one up to date. Let me know if this is a problem for you.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #925 on: 01 / January / 2013, 17:13:53 »
Quote from: reyalp on 01 / January / 2013, 15:41:58
No YUV, not sure if it exists on digic > 2, or how to find it.
I plan to do this on a DryOS cam sooner or later. I simply dumped all RAM from the filewrite hook routine, used the usual hex editor with the visualization, and after that I looked up the found address in fw. That said, it's easier to do on a camera with 16MB of RAM than on another with 64 or 128... .

Quote
I also wasn't clear how MAX_CHUNKS_FOR_JPEG is determined. 3 seems to work. I assume the structure is OK, since I get a valid jpeg.
Again, I dumped that specific piece of RAM from the filewrite hook (on D10, sub_FFA26268_my gets a pointer to it in R0), length is less than 0x80. Actually, that pointer is received by the task via ReceiveMessageQueue (sub_FF826C30).
Do you have a idea how a "message" handled by the *MessageQueue functions should be called? I usually just call it message, but I don't know whether it's good enough terminology...
edit: The VxWorks programmer's guide also uses "message", so it is correct.

After seeing several cam's filewritetask code, I can usually identify MAX_CHUNKS_FOR_JPEG, look at the code sub_FFA263B4_my starts with.

Quote
I was thinking about removing the all in one "remoteshoot" command and associated functions from chdkptp, so we only have to keep the lua based one up to date. Let me know if this is a problem for you.
No problem, just do it.

For YUV, there's libyuv. Yeah, it's just a library, and I haven't checked whether it actually supports the YUV variants we deal with here.
« Last Edit: 01 / January / 2013, 18:41:45 by srsa_4c »
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #926 on: 01 / January / 2013, 19:24:47 »
I've removed the old "remoteshoot" function along with the support functions and PTP_CHDK_RemoteCaptureInit protocol command. Development version bumped since this changes the numbers. chdkptp >= r319 supports this version.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #927 on: 01 / January / 2013, 19:47:41 »
Quote from: srsa_4c on 01 / January / 2013, 17:13:53
For YUV, there's libyuv. Yeah, it's just a library, and I haven't checked whether it actually supports the YUV variants we deal with here.
It would be nice to get a proper conversion of this YUV to see how it really compares to jpeg. Given that it's only available in reduced size (for cameras so far), it seems like it's unlikely to be better than full res jpeg. I can imagine automation projects that wanted to look quickly look at a small part of the images might like YUV, since we can't really return a sub-range of jpeg. OTOH, the YUV actually comes out bigger than the correspond raw...

ImageMagic will convert some YUV formats, but the one I tried (-sampling-factor 4:2:2) gave basically the same result yuv2pnm. I always get lost looking at the imagemagick documentation...
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: CHDK PTP interface
« Reply #928 on: 01 / January / 2013, 20:24:13 »
Quote from: srsa_4c on 29 / December / 2012, 13:26:29
I'm considering the simplification of filewrite_main_hook()'s arguments. If the FileWriteTask data block is mapped to a camera-specific structure, only a pointer would be needed as a single argument. It would also make the assembly (glue) part simpler and the code less ugly.
It looks like this (camera specific capt_seq.c):

For DryOS>=r50
Code: [Select]
typedef struct {
    unsigned int address;
    unsigned int length;
} cam_ptp_data_chunk; //camera specific structure

#define MAX_CHUNKS_FOR_JPEG 7 // filewritetask is prepared for this many chunks
/*
 * fwt_data_struct: defined here as it's camera dependent
 * unneeded members are designated with unkn
 * file_offset, full_size, seek_flag only needs to be defined for DryOS>=r50 generation cameras
 * pdc and name are always needed
 */
typedef struct
{
    int unkn1;
    int file_offset;    // needed for DryOS>=r50
    int full_size;      // needed for DryOS>=r50
    int unkn2, unkn3, unkn4;
    cam_ptp_data_chunk pdc[MAX_CHUNKS_FOR_JPEG];
    int seek_flag;      // needed for DryOS>=r50
    char name[32];
} fwt_data_struct;
#define FWT_MUSTSEEK    2   // value of seek_flag indicating seek is required
#define FWT_CONDSEEK    3   // value of seek_flag indicating seek is required when file_offset not 0
Example of an earlier DryOS camera
Code: [Select]
typedef struct {
    unsigned int address;
    unsigned int length;
} cam_ptp_data_chunk; //camera specific structure

#define MAX_CHUNKS_FOR_JPEG 3 //model specific
/*
 * fwt_data_struct: defined here as it's camera dependent
 * unneeded members are designated with unkn
 * file_offset, full_size, seek_flag only needs to be defined for DryOS>=r50 generation cameras
 * pdc and name are always needed
 */
typedef struct
{
    int unkn1, unkn2, unkn3, unkn4, unkn5;
    cam_ptp_data_chunk pdc[MAX_CHUNKS_FOR_JPEG];
    char name[32];
} fwt_data_struct;
Which makes the assembly glue simpler:
Code: [Select]
//place hook here
      "STMFD SP!, {R4-R12,LR}\n"
      "MOV R0, R4\n"
      "BL filewrite_main_hook\n"
      "LDMFD SP!, {R4-R12,LR}\n"
//hook end
I guess it's better. I have a feeling that cam_ptp_data_chunk will go into a common header as it's always the same.
Logged
*

Offline reyalp

  • ******
  • 14080
Re: CHDK PTP interface
« Reply #929 on: 01 / January / 2013, 20:48:04 »
Quote from: srsa_4c on 01 / January / 2013, 20:24:13
I guess it's better. I have a feeling that cam_ptp_data_chunk will go into a common header as it's always the same.
Agreed. I would expect  fwt_data_struct is very likely tied to dryos rev, so could be in a common header with a minimal number of ifdefs.
Logged
Don't forget what the H stands for.
Pages: 1 ... 88 89 90 91 92 [93] 94 95 96 97 98 ... 125   Go Up
« previous next »
 

Related Topics