Sorry for my late reply!
I understand compress_task() is not the right place to put the code, but as of now being "a convenient place" is all I need since I'm just doing preliminary tests.
As I previously said I'm a java developer and C is not my main language. Furthermore, my previous experience with C (and C++) is more with desktop applications development. So I'm aware I'm not the right person to be involved with these tests, but I want to try it anyway and perhaps, in case of some positive results, someone else could improve my work.
Yesterday I have been able to check a bit more inside the code and I have understood something.
More in detail, I have been able to change the values of part of the image acquired putting this code inside compress_task() right before the call to lossless_compress_raw_rectangle(...):
The code to access the value of the sample is very inefficient (I took the code from the functions to read/write a sample in raw.c and could be ok for a random access, not for sequential) and must be highly optimized (or, better, rewritten) but for now what I find surprising is another thing:
I can extend the process to the full frame of the image and have no delay if I avoid the write of the samples, while keeping the writing I can't extend it much more than 100x100 pixel without becoming choppy (even liveview will be slow).
I mean: it was expected to be hard to do it in realtime, but I don't understand why only the writing portion of the code is taking alot of time. It looks pretty similar to the reading, to me, while in comparison it seems to take like 100x more time to write the sample.
Any opinion about it?
I understand compress_task() is not the right place to put the code, but as of now being "a convenient place" is all I need since I'm just doing preliminary tests.
As I previously said I'm a java developer and C is not my main language. Furthermore, my previous experience with C (and C++) is more with desktop applications development. So I'm aware I'm not the right person to be involved with these tests, but I want to try it anyway and perhaps, in case of some positive results, someone else could improve my work.
Yesterday I have been able to check a bit more inside the code and I have understood something.
More in detail, I have been able to change the values of part of the image acquired putting this code inside compress_task() right before the call to lossless_compress_raw_rectangle(...):
Code Select
unsigned int s = 0; // will get the sample value
for(int pos_y = 900; pos_y < 1000; pos_y++) { // should be extended from 0 to raw_info.height
for(int pos_x = 900; pos_x < 1000; pos_x++) { // should be extended from 0 to raw_info.width
struct raw_pixblock * p = (void*)fullSizeBuffer + pos_y * raw_info.pitch + (pos_x/8)*14;
// get the value of the sample
switch (pos_x%8) {
case 0: s = p->a; break;
case 1: s = p->b_lo | (p->b_hi << 12); break;
case 2: s = p->c_lo | (p->c_hi << 10); break;
case 3: s = p->d_lo | (p->d_hi << 8); break;
case 4: s = p->e_lo | (p->e_hi << 6); break;
case 5: s = p->f_lo | (p->f_hi << 4); break;
case 6: s = p->g_lo | (p->g_hi << 2); break;
case 7: s = p->h;
}
s |= 0x0FFF; // just an example of sample value changed
// write the new value of the sample
switch (pos_x%8) {
case 0: p->a = s; break;
case 1: p->b_lo = s; p->b_hi = s >> 12; break;
case 2: p->c_lo = s; p->c_hi = s >> 10; break;
case 3: p->d_lo = s; p->d_hi = s >> 8; break;
case 4: p->e_lo = s; p->e_hi = s >> 6; break;
case 5: p->f_lo = s; p->f_hi = s >> 4; break;
case 6: p->g_lo = s; p->g_hi = s >> 2; break;
case 7: p->h = s; break;
}
}
}
The code to access the value of the sample is very inefficient (I took the code from the functions to read/write a sample in raw.c and could be ok for a random access, not for sequential) and must be highly optimized (or, better, rewritten) but for now what I find surprising is another thing:
I can extend the process to the full frame of the image and have no delay if I avoid the write of the samples, while keeping the writing I can't extend it much more than 100x100 pixel without becoming choppy (even liveview will be slow).
I mean: it was expected to be hard to do it in realtime, but I don't understand why only the writing portion of the code is taking alot of time. It looks pretty similar to the reading, to me, while in comparison it seems to take like 100x more time to write the sample.
Any opinion about it?