A800 Porting Thread - page 15 - DryOS Development - CHDK Forum
« previous next »
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 28   Go Down

A800 Porting Thread

  • 277 Replies
  • 121125 Views
*

Offline reyalp

  • ******
  • 14138
Re: A800 Porting Thread
« Reply #140 on: 18 / March / 2012, 23:18:35 »
Advertisements
Quote from: srsa_4c on 18 / March / 2012, 23:00:26
Quote from: philmoz on 18 / March / 2012, 22:35:37
It would appear to be the first time the filesize has matched; but the bayer pattern hasn't.
Bernd R has been fighting with something similar on the Ixus1000
http://chdk.setepontos.com/index.php?topic=5722.msg82387#msg82387
I think this is a different problem, though I'm not clear what the actual problem is. If it was the same problem, then DNG would work with the appropriate CFA pattern.
Quote
Quote
The bayer pattern is 2x2 so you should strip the bottom 2 rows to avoid having an odd image height.
:-[
Anyway, if a method like this is decided, the black and shadow areas have to be taken into account (i.e. not chop away rows that actually contain some useful image data).
We could also add two rows of black pixels for the same effect, with no loss of data.

It's a clever idea, but I don't think we should go this way. DNG and dng4ps2 give people options for working with these images.

If we want to make "CHDK raw" reliably identifiable, IMO we should go the whole way and make our own image format. My favored option is a minimal CHDK header, plus a DNG without the bytes swapped or badpixels patched. This is trivial to convert to either a DNG, or back into a traditional CHDK framebuffer dump, but won't be accidentally identified as a DNG or other TIFF based format. Assuming we could convince dcraw to support it, all the dcraw based programs would pick it up eventually. The current raw would then be relegated to a debugging tool.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: A800 Porting Thread
« Reply #141 on: 18 / March / 2012, 23:27:27 »
Quote from: reyalp on 18 / March / 2012, 23:18:35
If we want to make "CHDK raw" reliably identifiable, IMO we should go the whole way and make our own image format. My favored option is a minimal CHDK header, plus a DNG without the bytes swapped or badpixels patched. This is trivial to convert to either a DNG, or back into a traditional CHDK framebuffer dump, but won't be accidentally identified as a DNG or other TIFF based format. Assuming we could convince dcraw to support it, all the dcraw based programs would pick it up eventually. The current raw would then be relegated to a debugging tool.
Sorry - but what does that buy us (other than a little camera processing time) versus just making DNG the default format ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: A800 Porting Thread
« Reply #142 on: 18 / March / 2012, 23:47:50 »
Quote from: srsa_4c on 18 / March / 2012, 23:00:26
Bernd R has been fighting with something similar on the Ixus1000
http://chdk.setepontos.com/index.php?topic=5722.msg82387#msg82387

Different issue - from what Brend R has posted it would seem the IXUS 1000 uses a new bayer pattern not seen previously on any other Canon camera.

AFAIK all other cameras use one of:
R G
G B
or
G B
R G

The IXUS 1000 seems to use:
G R
B G

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: A800 Porting Thread
« Reply #143 on: 18 / March / 2012, 23:52:01 »
Quote from: waterwingz on 18 / March / 2012, 23:27:27
Quote from: reyalp on 18 / March / 2012, 23:18:35
If we want to make "CHDK raw" reliably identifiable, IMO we should go the whole way and make our own image format. My favored option is a minimal CHDK header, plus a DNG without the bytes swapped or badpixels patched. This is trivial to convert to either a DNG, or back into a traditional CHDK framebuffer dump, but won't be accidentally identified as a DNG or other TIFF based format. Assuming we could convince dcraw to support it, all the dcraw based programs would pick it up eventually. The current raw would then be relegated to a debugging tool.
Sorry - but what does that buy us (other than a little camera processing time) versus just making DNG the default format ?

Faster to save (reverse bytes takes a lot of time).
Eventually, no more 'why can't I view/process the CHDK raw file' questions (assuming it used a new file extension to avoid the clash with the Canon file extensions).

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline srsa_4c

  • ******
  • 4451
Re: A800 Porting Thread
« Reply #144 on: 19 / March / 2012, 00:13:21 »
Quote from: waterwingz on 18 / March / 2012, 23:27:27
... (other than a little camera processing time) ...
Exactly.
The benchmark shows a memory writing speed of
~45MB/s on a DIGIC II (A420) and two DIGIC III cameras (A470, SX100)
~90MB/s on a DIGIC 4 (Ixus870)
The byte swapping process runs probably slower than that.

@philmoz
My guess is that Canon has reconfigured the (readout of the) sensor somehow. Or it's not the same as in the Ixus300, despite having the same dimensions and resolution.
Can the new variant be made supported?
Logged
*

Offline philmoz

  • *****
  • 3450
    • Photos
Re: A800 Porting Thread
« Reply #145 on: 19 / March / 2012, 00:36:30 »
Quote from: srsa_4c on 19 / March / 2012, 00:13:21
Quote from: waterwingz on 18 / March / 2012, 23:27:27
... (other than a little camera processing time) ...
Exactly.
The benchmark shows a memory writing speed of
~45MB/s on a DIGIC II (A420) and two DIGIC III cameras (A470, SX100)
~90MB/s on a DIGIC 4 (Ixus870)
The byte swapping process runs probably slower than that.

Byte swapping takes ~300ms on the G12 (10MP).
For cameras without multiple RAW buffers (or if this hasn't been implemented) the byte swapping has to be done twice.

Quote
@philmoz
My guess is that Canon has reconfigured the (readout of the) sensor somehow. Or it's not the same as in the Ixus300, despite having the same dimensions and resolution.
Can the new variant be made supported?

Or someone mounted the color filter rotated 180 degrees :)

Phil.
Logged
CHDK ports:
  sx30is (1.00c, 1.00h, 1.00l, 1.00n & 1.00p)
  g12 (1.00c, 1.00e, 1.00f & 1.00g)
  sx130is (1.01d & 1.01f)
  ixus310hs (1.00a & 1.01a)
  sx40hs (1.00d, 1.00g & 1.00i)
  g1x (1.00e, 1.00f & 1.00g)
  g5x (1.00c, 1.01a, 1.01b)
  g7x2 (1.01a, 1.01b, 1.10b)
*

Offline reyalp

  • ******
  • 14138
Re: A800 Porting Thread
« Reply #146 on: 19 / March / 2012, 01:27:18 »
Quote from: waterwingz on 18 / March / 2012, 23:27:27
Sorry - but what does that buy us (other than a little camera processing time) versus just making DNG the default format ?
1) Faster.
The "little processing time" is a good half second or more on many cameras.
2) No badpixel
2a) no requirement to create it
2b) no memory lost to badpixel file. On some cameras it's large enough to be an issue.
2c) slightly faster
As we discussed on IRC, we might also be able to avoid badpixel by using DNG 1.3 opcodes.
3) More flexible.
While the most basic form is just an encapsulated DNG, it could be extended in useful ways. Two things come to mind - adding arbitrary meta-data from script, and saving only part of the framebuffer.

Quote from: srsa_4c on 19 / March / 2012, 00:13:21
~90MB/s on a DIGIC 4 (Ixus870)
The byte swapping process runs probably slower than that.
D10 digic 4, 12mp, ~90MB/s in benchmark. Raw is 17.8 mb.  Needs to be read, reversed written twice (only 1 raw buffer, need to get it back in the right order for jpeg) = ~70 mb total over the bus.

So the ideal case at 90mb/s would be ~0.77 sec. Actually, it's a bit faster, because reversebytes is optimized ASM using LDM/STM and the benchmark isn't ;)

The only possibility I see for major improvement would be figuring out how to do the reversing in parallel to writing to the SD card. Maybe your research in the movie stuff would be help figure this out.
Logged
Don't forget what the H stands for.
*

Offline waterwingz

  • ******
  • 12140
    • Waterwingz
Re: A800 Porting Thread
« Reply #147 on: 19 / March / 2012, 07:53:57 »
Quote from: reyalp on 19 / March / 2012, 01:27:18
1) Faster.
The "little processing time" is a good half second or more on many cameras.
Which matters.  But I sometimes forget this as it gets lost in time to transfer a 15M image transfer from my G10 to a Class 2 SD card.

Quote
While the most basic form is just an encapsulated DNG, it could be extended in useful ways. Two things come to mind - adding arbitrary meta-data from script, and saving only part of the framebuffer.
Fun stuff.  Although the partial framebuffer stuff sounds a bit like "digital zoom" :)

I guess my biggest worry is a new format that nobody can use (easily) and all the flap that will cause.  Maybe getting  the dcraw guy to agree to add it right away (no longer needs to be 'per camera') would help - or "we" release a conversion utility (yawn).   

I suppose it could be added to the RAW menu as a 3rd option for how to store the image but ....

Update :  should we ask someone (philmoz?) with admin rights to move the last bunch of posts to a new thread or are we done here for a while ?
Logged
Ported :   A1200    SD940   G10    Powershot N    G16
*

Offline Microfunguy

  • ****
  • 4037
    • StereoData Maker
Re: A800 Porting Thread
« Reply #148 on: 19 / March / 2012, 08:38:17 »
Quote from: reyalp on 18 / March / 2012, 23:18:35
My favored option is a minimal CHDK header, plus a DNG without the bytes swapped or badpixels patched.

Which is what SDM does.
Logged
*

Offline Qanthelas

  • **
  • 71
Re: A800 Porting Thread
« Reply #149 on: 19 / March / 2012, 12:49:23 »
Alright, just to make sure, grabbed the latest build from http://mighty-hoernsche.de/trunk/ which is a800-100c-1.1.0-1754-full_BETA.zip and did the same test - take a RAW, create badpixel.bin, turn on DNG, take another picture.  This time the .CR2 is of a pen, a yellow mini-postit note pad, and my sd card reader cap and the DNG is mainly of a Weighted Companion Cube plush that I made (because I'm cool like that.)  I see the .CR2 as purple and the .DNG as just fine color-wise. I'll be doing some more tests on this build Soon(TM).

http://www.box.com/s/22d7d6a9e14f1d82e8d2

This version shows Free Memory of 349600 bytes and CHDK size of 222544 bytes.  The Draw Test works just fine but the Set Mode test - both .lua and .bas - errors out as it did in waterwingz's builds.
The setmode log file:
Code: [Select]
a800 100c CHDK 1.1.0-1754 Mar 19 2012 07:28:39 dryos 0x3226
START                        |                 AUTO   1 32768 STL
TRY                 AUTO   1 |                 AUTO   1 32768 STL  270ms OK
TRY                    P   2 |                 AUTO   1 32768 STL  280ms CHANGE FAIL req   2 got   1
TRY            VIDEO_STD   9 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req   9 got   1
TRY        SCN_KIDS_PETS  33 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  33 got   1
TRY         SCN_PORTRAIT  41 |                 AUTO   1 32768 STL  280ms CHANGE FAIL req  41 got   1
TRY           SCN_SUNSET  55 |                 AUTO   1 32768 STL  260ms CHANGE FAIL req  55 got   1
TRY     SCN_LONG_SHUTTER  60 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  60 got   1
TRY         SCN_LOWLIGHT  64 |                 AUTO   1 32768 STL  260ms CHANGE FAIL req  64 got   1
TRY  SCN_FACE_SELF_TIMER  78 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  78 got   1
TRY          SUPER_VIVID  83 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  83 got   1
TRY        POSTER_EFFECT  84 |                 AUTO   1 32768 STL  260ms CHANGE FAIL req  84 got   1
TRY                BEACH  87 |                 AUTO   1 32768 STL  280ms CHANGE FAIL req  87 got   1
TRY              FOLIAGE  88 |                 AUTO   1 32768 STL  260ms CHANGE FAIL req  88 got   1
TRY                 SNOW  89 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  89 got   1
TRY             FIREWORK  90 |                 AUTO   1 32768 STL  260ms CHANGE FAIL req  90 got   1
TRY       BLUR_REDUCTION  93 |                 AUTO   1 32768 STL  270ms CHANGE FAIL req  93 got   1
TRY                 AUTO   1 |                 AUTO   1 32768 STL  270ms OK
I'm guessing this is just a matter of what options are used for compiling, but I'm not sure.
« Last Edit: 19 / March / 2012, 13:36:53 by Qanthelas »
Logged
Pages: 1 ... 10 11 12 13 14 [15] 16 17 18 19 20 ... 28   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal