I-Appliance BBS The Official Source for Internet Appliance Upgrades and Mods BBS Main List | Sign In | Sign Up | Search | Help | Linux-Hacker.net Reply to Thread | Printer |

Home / MISC Areas / Cameras Decompression - 1 2 many 4 all Decompression - 1 2 many 4 all

Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile The final phase! Post all decompression discoveries, questions and suggestions here. Starting with reposting of some of mine and one of Drmn4eas: Too many coincidences – it has to be JPEG! Are you ready, sit back and enjoy some factorization: allblack compressed image has 52187 repetitions of 9 bit pattern. 52164 + 23 = 52187 =(23*2269) 23 I can't explain. The same repeating 9 bit pattern can be seen in all whites. I created an all white and all black 1288 by 864 image in Raw Photodesk and saved in jpg format. They both had 4347 repetitions of A2 8A 28. Now 4347*3*3 = 52164 same as above. If we have 8*8 blocks then 1288/8 = 161 and 864/8 = 108 and 161*108*3 =52164. Now forget about a 9 bit pattern, it makes more sense to think of it as a repeating group of 9 bytes. If you can see that the camera image has three times as much data per block then please take over from here and create some headers for us all. The JPEG headers mentioned in my post on discoveries might already exist somewhere in the downloaded files of raw data. Please can someone download Raw Photodesk create the all white and all black 1288*864 images and look for similar header patterns on our raw images. Drmn4ea: I just created an allblack JPEG image of size 1288x864 in PSP with the absolute minimum compression, but it's still only 6845 bytes including all headers. The data area (minus qtables) is all $00s. I saw in another thread you mentioned getting repeating A2 8A 28 in a similar file from Raw Photodesk; how did this happen with all black/white input? (/me needs to read the specification again, but it sounds odd). I'm still leaning toward a raw format; the data looks to me like it's split up into (58716 / 9 = 6524) data blocks individually encoded/compressed; the last one not all the way used. Closer on Decompression? I created a raw 1288x864 byte file of just zeros (like Drmn4ea's cut line black). I forget exactly how but think I loaded a large file into XVI32 stripped it to that size and saved it as black.raw, then opened it again and copy and pasted 2 more copyies to have a complete 24 bit RGB raw image of zeros. I then downloaded icae1: http://www.ggcomputer.com/icae.htm . Under advanced edits this allows quick size comparisons without storing file. The best I have found are lossless jpeg using dct ifast and photometric cmyk, or tiff using packbit compression and photometric cielib or rgb. You need to first enhance colors and reduce r,g,b to 0 to get rid of upper left corner unregistred message which is a real pain and may be throwing off hex comparison in final files since you can not store without the message. If anyone has a registered version they have an advantage. Use Drmnr4ea's latest cut line black (somewhere above) to compare against probably starting near $12000. I have only been using Drmn4ea's cut line black. Someone should try one of the highly compressed white raws converted using boodle's raw2rgb. The quickest comparison is one of resulting size using icae1. I think I have limited it to tiff or jpeg, but both have repititions of 3 bytes rather than 9 bytes. Perhaps with a 500 extended dynamic range there is another byte in 24 bit RGB making it a 32 bit LRGB (Luminance corrected rgb) and adding that to an input before compression could somehow cause a 9 byte pattern instead of 3 bytes. 12-13-2004 08:57:13

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile The last nail: In LRGB format, each pixel is represented by 9 values, namely the six polynomial coefficients aiI, 0 ¡Ü i < 6, that model its luminance as a function of the light direction, and the three Red, Green, and Blue (R,G,B) color components. From: http://www.cs.brandeis.edu/~gim/Papers/HPL-2000-143R2.pdf . Now would someone please show me what my high dynamic range Cadillac looks like, I am contracting at Ford and it would be inappropriate for me to do so! 12-13-2004 13:42:01

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile The LRGB might just be wishful thinking. I have been looking at my saturated whites and there is a clear uncompressed raw pattern of 1284 FFs, followed by 4 low value XXs. Looking closely at the compressed version I am seeing something like 543 by 76 (or 75, going blind now and can’t count anymore) of pattern of on bits only broken every 9th bit. I would appreciate it someone else could verify exactly whether that pattern does break the same for each row using my 543, 75, 543, 75 pattern or one adjusted up or down a bit or two. I did not make it to the end of a row to see what happens there. Its grueling but an easy conceptual pattern to break down - again look for where the off bits break a stream of 8 on bits at both ends of the old "60 9 bit repetition" (I believe it is longer by 3 bits - 540+3). 12-13-2004 18:58:21

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile I did a little analysis of a black-to-white image I took. I graphed out what seems to be a common end of line marker ( 7FBF DFEF F7FB FDFE FF ) in the image. That exact string was found 145 times in the compressed image. A interesting thing is the curve seems to be a gamma correction curve or something similar. I am going to dig around and try some other images to play with. I am just trying to think what I would use two 9 bit curves to represent. Can colour intencities be represented by a curve? More detailed explanation and graphs here I also I found it odd that the sequence is 9 bytes long. That number seems to show up a lot... 12-13-2004 22:04:03

RE:Decompression - 1 2 many 4 all (modified 0 times) taytrr Profile The autobrite documentation refers to different lighting levels withing each image. Maybe the curves represent area/intensity/size of an adjustment bubble? See example at www.smalcamera.com/technology.html 12-13-2004 22:27:22

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile Hmmm... I looked at a few other images and I think I am really wrong. The all white one has the same curve I was playing with but has 5704 of them in a all white raw image. I looked around and couldnt find the cut black raw file. Anyone remember where it went? 12-13-2004 22:28:56

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile Latest cutline black was posted in Discoveries by Drmn4ea: http://www.cexx.org/dakota/pv2stuff/dumps/ select allblack.zip which contains allblack3.dat . 12-13-2004 23:21:25

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile The first of my 2 allwhites (white1.raw) from Links - 1 2 many 4 all, contains shorter sequences for the 4 reference pixels at the end of each row at the bottom of image. There were several 02 00 00 00 in the uncompressed which compressed to only 40 bit strings as compared to the 75,76 I was seeing at the top. While they were shorter they were far from the same. Does anyone know of a good binary bit viewer? I think this white with plenty of zeros in the last 4 bytes of 1288 byte row should aid in deciphering. I can see those positions in the compressed file and they are certainly smaller when zero values are present but can't decode. There may be an address decrement that points to first occurrence of string (that would make it different each time). 12-13-2004 23:40:52

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile I gave the images a quick one over. It is interesting there are still what looks like 5704 groups of that string for both the white and the black image. I did some searching on autobrite. This guy made a gphoto driver info I looked at the code and there is some bayer and gama stuff. He says "The camera returns a RAW image with a bunch of extra data, which I guess are parameters for post processing"... and later on the updates page he says "An interesting note is that it returns (AFAICT) the same data for a 1024x768 image as for a 640x480 ..." I read in one of FujiFilm's pdf's that their software will process the image into a jpeg for you. Maybe that is some of the data that they are messing up our nice raw images with. Possibly 'half' processing it before hand. It is also possible that they are throwing away a lot of data ( half the green ? ) and just storing something else. If that is true, maybe someone can look into the jpeg processing routines and see what the intermediate steps look like. The images are obviously more compressable than they are, could they be jpg minus one final step? I'll try and check this out when I get some time. I've been thinging it may be possible that they are working with weird sized numbers... ie base 9, 18 or larger and the chunks we are seeing ( look at graphs at bottom of page I linked to in my last post ) are the significant bits in the number. I think some investigation into the firmware is in order. Has anyone written any code to suck the flash out? I haven't gotten around to it and it is too much work to do manually with the usbpoker. And even though I merged my firmware together I am not sure I got a 100% pure copy ( I have one unknown oppcode and some odd data sections ) 12-14-2004 00:36:37

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile I think they may be leaving out a step in jpeg check this out: JPEG compression is confusing, as even JPEG advocates will , so a summary may help make matters clearer. JPEG compression follows these steps: source 1 Separate a color image array into one luminance array and two chrominance arrays. 2 Break the arrays into 8x8 blocks. 3 Perform a discrete cosine transform (DCT) on the blocks to obtain blocks of corresponding harmonic coefficients. 4 Quantize the values in each coefficient block using a quantization table with scaling values for each element in the block. 5 Convert the quantized coefficient block into a 64-element linear array using "zig-zag scan". 6 Compress the first (constant) element in the linear array by performing delta modulation between arrays. 7 Compress the other 63 elements of a single block using lossless run length encoding (RLE). 8 Perform Huffman coding on the all the results. My guess, and it is a guess: They have modified step 2, The 9 bits may be from a 3x3 matrix, not the 8x8 that is the jpeg standard. Then they stop after step 6 or 7. I know they cant be doing Huffman as that would destroy all of our nice repeating 9bit pattern. 12-14-2004 01:16:59

RE:Decompression - 1 2 many 4 all (modified 0 times) scribble Profile bentfork--Nines and multiples of 81 are definately magic numbers. In the compressed version of my knee pictures the details such as the chevron are always seperated by 9 pixels. More interesting, if you produces the grey images with the width set at even multiples of 81 you see partial, complete or repetitive white patterns. The white patterns are complete at 4x81 and repetitive abd almost identical at 8X81 and 16x81. In addition, the misnamed checker board pattern rearranges itself into sloping diaginal lines where repetitive element are very visible. There may also be a seed involved since with my camera1 12x81 produced a very simplified pattern with 14x81 doing the same for camera2. My ritz red has arrived and sometime in the next day or so I hope to expand on your snowman idea and photograph white curved cutouts against a black background. I'll set up a tripod and take esentially identical pictures with all three cameras. Be interesting to see what happens. Boddle--I took my windows picture, used your raw2bmp and created a tonally accurate and correctly colored image in photoshop. I converted to Lab mode and used the levels tool on the L channel to set the black and white points and the gamma. To correct the color, I used the same tool on the a and b channel. Has anyone else observed the 255 byte signature I've been seeing. Somehow I managed to create two dumps where everything is all black except for the signature. In both cases the cable had problems, a broken and intermitant data wire and I'm wondering if the signature is an artifact from my computer. It always ends 4095 bytes after what the poker says is the end of the reguested dump Dakotamod--If you are looking for patterns in your data, you may want to try my visual technique. If you set things up right the patterns jump out at you. 12-14-2004 11:06:08

RE:Decompression - 1 2 many 4 all (modified 0 times) boodle Profile If the camera puts the compressed picture at 73886 in the memory and the uncompressed image starts at 1179649, they only left 1105763 bytes for the compressed image at the maximum size. If they claim that it's lossless storage, I don't think they are debayering before they store it. I think they're just working with 1288(or 1284?)x864=1112832(or 1109376?) pixels of RGRG GBGB data. Otherwise, they would be using a lossless compression that is guaranteed to compress any picture to less than one third of the original size. So if we're working with just the raw data, maybe they took all of the reds and put them together to make an image 644(642?)x432, all of the blues the same way, and maybe two images of green or just combining all the greens. I would think that splitting them up like this would give you better compression anyway, but I could be way off on all of this. Also, since there is only 1105763 of storage, what if they only store 1282x862? That would be 1105084 bytes, which is just less than the space they have left for it. It is also the number you would want to store if you want to do bilinear interpolation to get 1280x860, as it appears the resolution of the final pictures will be, but I can't remember whose web page had that. I think it was from nvram.dat? 12-14-2004 12:33:23

RE:Decompression - 1 2 many 4 all (modified 0 times) boodle Profile Actually I'm probably wrong on that last part. Don't they say it's 3 megapixels? so somehow they are interpolating to get 3 times the pixels. 12-14-2004 12:49:39

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile boodle, take a good look at your white posted in links. There are 5 allwhites, first 2 by daBass (missing uncompressed), 2 more by me, and one by boodle. They all start 00 55 21 FE FF, the cutline black starts 00 FE FF. It is easy to see the 4 reference bytes at the end of each 60 x 9 (up or down a bit or two maybe) compressed string and locate the corresponding uncompressed values at the end of each 1284 FF string in image starting at $120000. Each of the whites starts with approx 85 x 9 bit repetitions instead of the usual 60. Comparing 4 byte values between the 3 uncompressed whites and the corresponding compressed versions may help (many have only 1 nonzero bit). 12-14-2004 13:35:53

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile According to this google cached pdf article, ( the original pdf seems to have gone awol) ...apparently the camera uses a 1.2 megapixel imaging chip and the pictures are interpolated (“rezzed up”) to 2 megapixels by the server, the same as with the earlier Dakota model. ... Pure Digital says, “We leave only the bare minimum (technology) in the camera. . . Because of the separation of technology (between camera and server) we are able to get significant quality out of low-cost components.” We know the raw image size. We can guess the final image size. The question is has anyone gotten their prints back yet? I'll post a few shots if anyone has gotten their photo cd. I would love to see the final jpeg image sizes. 12-14-2004 13:39:43

RE:Decompression - 1 2 many 4 all (modified 0 times) Drmn4ea Profile @bentfork - if you're only after the root-directory files (firmware, etc.), you can request the entire first 2.8 meg (0x29FFFF) in a single transfer (just like the USB dumps so far), then use Mac/linux/chewfat to extract the files out of the flashdump. It shouldn't be necessary to take multiple dumps and piece them together (you're right, that's a lot of work!) unless trying to reconstruct an entire flash image full of pictures. Sometime when I'm not at work past midnight (Hi Gert! ) I'll try to hack up a special poker for Mass-Storage-Bulk-Only. In the meantime, here are the command files I've been sending to extract data. 12-14-2004 13:59:28

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile A suggestion for Drmn4ea, if/when you can write code back it would be nice to toggle a bit in the uncompressed cutline black sometime before compression is called. A few wisely chosen bits and we might get a lucky decipher. 12-14-2004 15:00:00

RE:Decompression - 1 2 many 4 all (modified 0 times) hoppsan Profile @bentfork I find this section of the pdf a lot more interesting ----------------------------------------- As for the future, Pure Digital also has plans for a very-low-cost video camera they say can shoot 20 minutes of high-quality video that will be processed in the store onto a DVD. ------------------------------------------ 12-14-2004 15:01:53

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile hoppsan Wow! I didn't see that. Maybe we should hold off on hacking this cam until that one comes out. ;) It is a clever buisness model. Once they get their machines into the stores, with network access they can upgrade software, track sales data etc. Adding more product lines seems like a rational idea. Its a marketeers dream. 12-14-2004 15:36:05

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile dakotamod you gave me a idea, we do have some known data in the white image: In the all raw all white image we get a black 4 pixel line on the right side of the image. This corresponds to 0x0000 0x0000 at positon 0x504, 0xAC0, 0xF14 etc. In the compressed image we have the nice logarithmic curve 7FBF DFEF F7FB FDFE FF that is occasionally interrupted by data. The interesting thing is that the curve is broken at different locations, and when it is the number of displaced bytes changes (graph here). If we look at the bit distortion of the curve we may be able to determine where within it the bits are, and how many there are, as some patterns seem to over lap multiple curves (fourth gap in image), while others are fully contained within one curve (second gap). 12-14-2004 16:12:52

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile bentfork, hold that thought. The first row has more of 9 bit pattern - just a theory but maybe rows are processed 64 bytes at time and since that does not evenly divide a row, it overlaps into the next row causing it to be shorter with 2 of the 4 byte black reference bytes now on each side of the overlapped row. This would continue for 8 rows before getting another row that started on a left boundary. Does your graph show that? I am really getting frustrated and am about to go get a 1.3 flatfoto at radioshack in hopes it may reveal internal compression (be a waste if it uses a completely different process). 12-14-2004 16:52:11

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile I searched back through old threads for flatfoto and found a link to a raw from it. Thanks, Pendragon445. " Here's the link to the sample flatfoto raw and jpg's for anyone interested. http://loveshack2003.tripod.com/photo.htm Don't worry about the title it's not an adult site...it's a reference to the B52's song. " I downloaded changed z to zip, and extracted 3 of 4 files (crc error on 4th). The raw file looks very familiar FE FF 7F BF ... with black reference bytes at end of rows. So do I get the flatfoto or stare at some more bits? 12-14-2004 17:35:24

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile Oh forgot the flatfoto driver link (need to leave now, been putting off getting a light bulb for my 3 times a lady). Good Luck. http://support.radioshack.com/soft.htm 12-14-2004 17:43:11

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile Thought I'd chip in my $.02 worth... Back in mid-September, both myself and one other person tried putting one of morcheeba's .RAW files onto an SD card, inserting it into the FlatFoto, and then seeing if the software would decode it. No go for either of us. However, now that we have more .RAW files to play with, perhaps it's worth-while to revisit that experiment? Also, doing side-by-side comparisons of Flat-Foto vs. PV2 all-black and all-white .RAW files might yield something useful. Oh yeah, one other thing. A while ago, I was looking at the all-white .RAW files (from the PV2), and noticed that the compressed picture data starts with 0x55, which is 85 in decimal. After that, it's followed by ~85 repetitions of the now-familiar 9-bit "111111110" pattern before getting a handful of seemingly random bytes. I'm convinced that this is not a coincidence, but so far have made zero progress getting past those first 85 reps. 12-14-2004 21:02:19

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile more autobrite info pretty pic it was linked to from this doc on image sensors. Autobrite (a) adjusts the illumination-versus-signal-strength curve to maintain detail in the dark and bright areas of a photograph, j_tetazoo, I remember the 9bit code. I am curious if/how the pattern itself gets modulated by the data. that shouldn't be too hard to do... Another thought is, the CMOS sensor is built by SMaL; could they be storing other image data near our raw image and muxing them together some how? 12-14-2004 21:58:45

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile j_tetazoo, Thanks for the work on my stop sign, without it icedragon may never have completed the photo. I am glad you are still lurking, it looks like icedragon was here for only a fleeting moment. Now that we have raw files, I think it should be alot easier to experiment with other software as a means of decompression (the flatfoto software does not seem to work with a previously downloaded file - it wants to start by downloading new files). Odd that 55, why have a repeat counter and do the repeating anyway. The size of your handful of random bytes after repetitions does vary based on compressable size of corresponding black reference bytes (when all but 1 bit is zero the repeating 9 bits starts sooner). The link I posted above points to a 640 x 480 flatfoto image which has the same repeating 9 bits but only half as many per line between the black reference bytes. 12-14-2004 22:12:32

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile Anyone know/ heard about HDR (High Dynamic Range) images? It came up when I was looking for autobrite like processes/procedures. It caused me to find some software HDR Shop They have some great info there on what HDR means. Basically it is a format for storing multiple images withing the same image. This allows them to have images that have 'brite brights' and 'dark darks', just Like your favorite laundry detergent. It uses floats to store image data to give it a wider range. It is really a clever idea. I played around with the tool and made some images that look very close to our cut-black compressed image. I started with a black image. The above mentioned tool has DCT's built in so I started playing. Check out the results and let me know what you think http://bentfork.gomen.org/CVSpv2/curve2.html 12-15-2004 01:06:00

RE:Decompression - 1 2 many 4 all (modified 0 times) morcheeba Profile bentfork - yeah, I agree PureDigital has been doing things right. I'm not certain of the ultimate utility of a single use digital camera, but their customers are retail stores, not actual users -- that's up to the marketing people to decide. It looks like another company has beaten PureDigital to the punch with a single use video camera. Anyone in Australia? AU$50 = USD$38 = EUR28 includes processing! more info 12-15-2004 01:24:13

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile Since we are in discovery mode, here is some more trial and probably error: To explain the initial 85, I start with a group of 21 repetitions. Then repeat it 60 times, followed by an ugly trailer compression of the last 28 bytes, then a new row with another 60 repeats of the first 21. The binary "FF" or "255" with eight on bits (the 9 bit sequence "111111110" may just be a marker to end repeats of first 21 pattern which itself is just repeats of either 4 00s (allblack) or 4 FFs (all whites) also containing the marker. So backwards 4 + 60 + 21 = 85. This would allocate 4 bytes per pixel - RGB and an Autobrite L. 12-15-2004 05:50:46

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile I'm thinking aloud here: Has anyone realise how close the all black and all white images are? The significance is the end of line markers, which in the all white raw contain 4 null bytes. The middle of the file is the same. It MUST to be autobrite saying that there is no significant difference in brightness/contrast. The other bits at the end of the line is it ramping up the contrast/auto whitebalance. (there are many ways to say autobrite) The middle of the file also contains more bytes than the beginning or the end. Possibly it is storing its spatial influence (the middle bytes are in the middle, so they can influence/beinfluenced by the top and bottom of the image). 12-15-2004 09:18:55

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile I am repeating myself, but so is the compression. There are other SMaL cameras that use same compression and make both a compressed.raw available along with a jpeg verions of it after download. We may even be able to extract the uncompressed raw using Drmn4ea's poker on these other cameras. If you have one please post some data, If you do not have one consider getting one; maybe SMaL's 2MP kit 4 instead of 1.3 kit 3 - then you'll have better pictures than the rest of us. 12-15-2004 10:00:14

RE:Decompression - 1 2 many 4 all (modified 1 times) icedragon Profile Whoa, heh, I'm not gone, Dakotamod! Have just had final exams here the last few weeks, which have positively been eating my time and all of my brain cycles. Still watching, still lurking, but admit I've lost track of the progress in the last few weeks. Where are we at? After Thursday I should have more time to devote to help on this. 12-15-2004 10:28:07

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile icedragon, glad to have you back. Finals - yuck been over 30 years since I did that. What a waste - I actually dropped out of High School in frustration for a week and only went back when my Dad offered me a new car (Austin Heally Sprite) to graduate. I do believe internet activities such as this may eliminate the ridiculous value of a degree. Where are we? morcheeba first and others shortly later have been reading flash (no writes yet). I finally managed to read flash last night (problems with XP and unlucky 13 byte trailer - documented in Questions). 12-15-2004 11:42:44

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile Doh! I just realized that my FlatFoto is a 640x480 model. No wonder I'm not having any luck getting its desktop software to decode a PV2 image. RadioShack now carries the FlatFoto MP2 which supports 1600x1200, 1280x960, and 800x600 modes. 12-15-2004 14:11:13

RE:Decompression - 1 2 many 4 all (modified 0 times) scribble Profile From reading some recent posts I think there is some confusion as to what Accubrite really does. Here a photographer's take on what is happening. First pull down the graph Bentfork linked to in his post on the EDN article. Which by the way is an excellent article on current sensor tecnology except for the noise section. Here the writer ignored the two main sources of noise in high and medium end cameras--Poisson noise and clean-out noise--the random way Mama Nature tosses photon in your camera lens; the up to 20 photoelectron that are left behind in the sensor well when the CCD or CMOS electronics tries to flush them out just before an exposure. Regardless of that, the graph illustrates my point. The linear portion shows what happens when you try to put too many photoelectrons in a sensor well. The electric field of the photoelections becomes larger than the fields holding them and they spill out into nearby sensors. This is what you see if you take a night shot with streetlights-- the area around the street lights turn into a saturated white blob. Add some Accubrite, and the saturated area becomes smaller and you see more detail in that area. Something on the plus side. But look what happens down at the bottom of the graph. With more and more Accubright it takes more and more light to create a grey level. So more and more of the detail away from the street light is disappearing into the noise. In ordinary photography, that's a massive something on the minus side. Now look at the mid tones. As you apply accubright you are applying a gamma correction. Without numbers it's hard to be certain, but from the shape of the curves it looked to me that too much accubright applies far too much gamma. So to get the mid tones right you'd have to apply a negative gamma (less than one) in order to pull them back so they look right. While not as massive as the disappearing shadow details, this is still a problem. That my first point. Accubright is great for a bank survailance camera since there's a chance you might get a pic of the stickup man before he pulls on his ski mask. But for ordinary photography it's the last thing you want or need. Second point and the reason I'm 99 and 44/100 percent certain PureDigital has no Accurbrite. Take a picture of your desktop. Use boodle's raw3bmp to convert the raw image and load it into your favorite image editor. Do a levels adjustment because the lens have gotten so bad the cameras consistantly underexposes by a stop or more when using flash. Then apply a standard gamma correction of 2.2 and some color correction of your choise If your image looks like your desktop-- it's a linear raw and no accubrite--the way my Ritz blues work. If your image looks totally washed with a gamma correction of between 4 to 5--than I'm wrong and you have Accubrite. scribble scribble 12-15-2004 14:19:15

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile scribble, Excellent analysis. I agree and even like your misspelling of Autobrite. Just do not misspell the brite – I much prefer that to bright – its shorter and why bother with silent letters. dakotamod, How long have you been here? Why didn’t you bother to read all of the work that came before you arrived. They had already eliminated jpeg and discovered most of your recent analysis. But no one came close to my discovery of the 23*2269 509 primes! You are still looking for tracks on thin ice that is about to break. What did you mean in last post where you claim to be repeating yourself? You seem to be suggesting we go buy a cheap camera from radioshack when we already have the same imager for far less? Why don’t you put your money where your mouth is and buy one of those receiving bad reviews? Have you lost all common sense. Amazing team work by Drmn4ea and morcheeba – pretty soon there will be no need to decompress, an anti DMCA college student just finishing finals will develop a firmware upload with better compression. 12-15-2004 17:45:35

RE:Decompression - 1 2 many 4 all (modified 0 times) scribble Profile Maybe I should come back with something like, "Sorry about that. What I meant to spell was No--accubrite which translates in SaleSpeak to LousyDark" but I must fess up to that I'd forgotten what the thing was called. scribble 12-15-2004 18:21:01

RE:Decompression - 1 2 many 4 all (modified 0 times) Godzilla Profile Hey, Right now I am a student in college, majoring in computer engineering. If there's anything my friends and I can do to help, please let us know. Our skills are somewhat limited at the moment, but as the quarters pass, we will become more and more knowledgeable. Also, Brite_eye, could you send me an e-mail please? Thanks. 12-16-2004 03:30:22

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Godzilla, what have you done with your 6520? Have you dumped firmware and disassembled it? If not have you reviewed and understood all the questions? What should I email you? Everything you need can be found in these threads. You should be asking those questions of moderator dakotamod. Do not answer but what do you think I am - an alter ego? Even that is fully answered just after the queen offs with my head in Questions. 12-16-2004 03:58:05

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile Drmn4ea's poker works with Radioshack Red! I cannot seem to download more than 1M, but that is enough to see the complete compressed file starting with the usual 00 55 21 FE FF 7F ... at $531. Most of the rest of the file appears to be random and I posted it without zipping since it barely made any difference. Here it is: http://briefcase.yahoo.com/zqcpwr Click on Red Radioshack and then allwhite.dump. Pictures downloaded using standard software from both Radioshack Red and Blue: http://www.photo.net/photodb/folder?folder_id=456596 I have been unable to get new software to read Pure Digital cameras - getting bootloader error. I tried unlocking my CVS blue, switching drivers and it still complained about bootloader. The about box of "MP Photo Album 2.2.2c" indicates portions are based on gd, png, jpeg, and zlib. 12-16-2004 06:31:56

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile Godzilla and others, Please download 1.3 Flatfoto MP Photo Album and drivers from http://support.radioshack.com/soft.htm and began hunting for decompression routine. 12-16-2004 07:17:03

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile I don't have a FlatFoto, but I now have the 1.3 Flatfoto drivers :) I suggest to anyone that actualy has the camera to open up the file smalusb.inf and look at the [SMALUSB.AddReg] section. There is a key that is commented out: ;HKLM,"System\Currentcontrolset\Services\SMALUsb\Parameters","DebugLevel",0x10001,2 If it wasn't commented out the installer would add a 'DWORD' value called DebugLevel with a value of 2 to the registry key at HKEY_LOCAL_MACHINE\System\Currentcontrolset\Services\SMALUsb\Parameters. If you add that key a log file should show up, somewhere. I suggest starting with the value 2. If two doesn't give you enough info try 0xFFFFFFFF 12-16-2004 10:50:17

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile Looks like it uses the kernels DbgPrint routine... You will probably need to install debugview to see the debug output. 12-16-2004 10:59:13

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile I hope 1.3 drivers prove to be all that is necessary. My first attempts with those failed. I only achieved success by using newer drivers that came with $79 Blue FlatFoto. Extracting my photos required using Drmn4ea's poker and command files to unlock camera, followed by a switch (not closing poker or unplugging camera) to new driver (using device manger update driver to change from libusb.inf to smxxxxx?.inf), and then starting ArcSoft PhotoBase® and from there as easy as pie in your eye. Note the red FlatFoto has hardware 04, firmware 4380, type 15; while the new blue has hardware 06, firmware 6620, and type 29 (more up todate than any of the Pure Digitals). 12-16-2004 16:16:38

RE:Decompression - 1 2 many 4 all (modified 0 times) boodle Profile brite_eye: Is there any way you could install the trial of Bus Hound? http://perisoft.net/bushound/ It lets you read usb reads/writes that happen with devices. It's pretty easy to set up, and it would let you know what the program is sending in order to download those pictures since it doesn't look like the driver you used is available online 12-16-2004 16:42:18

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Less than 2 hours of sleep in last 24 and still having fun! Could only get that eye http://www.photo.net/photodb/photo?photo_id=2834686 of mine half way closed, so here I am again - wish I could repeat myself (but cloning is taboo in this country). boodle, How can I resist a name like bus hound! I will try the trial, but consider that Radioshack has a 30 day return (read trial) policy. The Blue's are so irresistable it will be hard to return one - so just get one and start singing Da Blues! 12-16-2004 17:31:18

RE:Decompression - 1 2 many 4 all (modified 0 times) Godzilla Profile At the moment, I have not been able to connect my camera to my computer, mostly because since I am home on break, I do not have my soldering iron with me. I have been following along with the threads, and I understand what is going on for the most part. Once I can get that soldering done, I should be good to go. Also, brite_eye, please ignore my email request. I was up too late, and not thinking clearly. Sorry. 12-16-2004 18:32:02

RE:Decompression - 1 2 many 4 all (modified 0 times) scribble Profile Where do we stand? Is compression solved? Is there anything for a non programmer to do except sit back and wait for the perfect software package? 12-20-2004 13:27:41

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile scribble, I consider myself just a mear slacker hacker compared to others in this industry. Tonight I am taking my cameras along on a visit to a "Real computer" linux guy who refuses to operate in the windows world. Either we will complete the task at hand or hack happily till we drop. While this may just be a useless diversion, if we succeed there are several on this board capable of transporting a final open source solution to windows. 12-20-2004 14:28:29

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Here's a link to RadioShack FlatFoto drivers: http://support.radioshack.com/soft.htm (I haven't tried downloading & installing...) 12-20-2004 16:40:36

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Sorry about the last post - I didn't read back far enough to see that I was duplicating known info... I did some digging in the USPTO database. The patent number on the splash screen is currently assigned to "SMaL Camera Technologies" - is this clearly the Autobrite technology? Anyways... these guys seem to like patenting stuff. I searched for all patents with inventor name of "Fife, Keith" and found an application (i.e. not an issued patent, yet) for "In-stream lossless compression of digital image sensor data". A bit of reading explains that this is an on-the-fly method for processing and compressing the data from a digital camera image sensor data and storing it to FLASH memory. Hmmm... sounds like a perfect candidate for the PureDigital RAW format. Timing is right too - application is dated July 2004, right after the PV2 gets released. The description fits too - SMaL mentioned widely in press releases that their camera stores stuff in a lossless RAW format. I suppose the idea is that they can make a camera which compresses the raw image data to a proprietary format, then the "processing system" does the rest or the work. This lowers the horsepower needed in the camera since it doesn't have to handle the complexities of image processing or JPEG compression. Here's the link: http://appft1.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&u=%2Fnetahtml%2FPTO%2Fsearch-adv.html&r=4&p=1&f=G&l=50&d=PG01&S1=%28%22fife%2C+keith%22.IN.%29&OS=in/%22fife,+keith%22&RS=IN/%22fife,+keith%22 The algorithm is pretty rough reading because it has been reformatted into "patent-speak" text. Man, I wish they allowed pseudocode in patents... The next thing I would do is to try following the algorithm against all-black sensor data and see if it comes up with the bit stream in the all-black RAW file. 12-21-2004 00:19:25

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile sailpix, You have made me feel so stupid; why did I just search granted patents and not applications at US patent office site. Will it become a patent, and if so when? I believe we can use the method until pending patent is granted. Many patents are granted that are invalid - but that requires considerable court costs to prove, hopefully an examiner will recognize this as prior art. IF it takes closer to 3 years (1-3 is expected), than we probably have little or no concern. LEGAL help anyone PLEASE - I wonder if someone creates open source and does not use or sell it, but posts it for others - can it be removed from a download site after a patent is granted? I can't seem to get at figures and drawings (can on granted, can't on applications). I do not plan on wasting anymore time trying to decipher decompression until I or someone else checks patent algorithm against cutline black and saturated whites. From what I just read - it fits better than anything else. 12-21-2004 02:03:31

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile the image signal is compressed as still picture data by the compression circuit 5. the "compression circuit" Sound like hardware to me. I am guessing that the entropy reduction they are talking about is a reversable hash function of some kind. Since the smal software is willing to decode the images for us I think that is the way to go. Unfortunately I didnt find a DecompressSmalRaw() function yet. Something close but nothing usable yet. 12-21-2004 08:53:07

RE:Decompression - 1 2 many 4 all (modified 0 times) dakotamod Profile bentfork, please look at morcheeba's latest discovery! 12-21-2004 09:38:05

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile Somehow I managed to plow through that patent application without getting lost. I should point out that it looks to me like it was originally filed in Oct. 2002. I'd guess it's due to be granted or denied any day now (typical incubation is ~2yrs, or so I'm told). Here's my summary of how this invention works: 1) Convert the "pixmap" from the Bayer filter into a "difference map" by subtracting the value of the current pixel from the value of the pixel 2 positions to its left (this is to accommodate the Bayer filter). 2) Take each difference value and split it into multiple channels (they're fond of 3). 3) Compress each "channel stream" independently using "arithmetic compression". 4) Multiplex the compressed data back together into a single data stream. Steps 1 and 2 are pretty straight-forward and well-described. However, they seemed to assume a lot of knowledge of how "arithmetic compression" works, making use of histograms and such. Not being at all familiar with arithmetic compression, that part did throw me for a bit of a loop. One more thing... Observe the following paragraph: [0097] It is therefore found that the extra hardware required for the additional add-shift operation is offset by the corresponding resulting compression improvement. In one preferable implementation, a guard register of eight bits can be used to reduce the carry-over effect, and bit stuffing can be employed when the carry-over register happens to fill with eight or more successive 1's. The encoding operation can be divided into parallel operations to enable further enhanced channel splitting; here it must be recognized that there exists a tradeoff between the resulting enhanced efficiency and a requirement that the arithmetic encoder, containing a relatively complex signal path with a multiplication and complex decision tree, would need to be replicated. I think the part about bit-stuffing with eight or more successive 1's explains the mysterious "111111110" pattern we're seeing in the all-white images. 12-21-2004 14:53:11

RE:Decompression - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Argh, beaten again! And I haven't even slogged through the whole app yet. Anyway, pardon the mess, just me thinking out loud. (Maybe this should go under 'Annoying Posts') Was skimming the patent application - assuming the scheme that's in the application is the same one that's in the camera (it may not be, entirely at least; this "in-stream" stuff sounds related to the hardcore realtime video compression Fife was involved with, it doesn't seem necessary on a still camera), sounds like the first steps are: (note: "maybe" syntax here because the patent app tries to cast a wide net around every possible combination of these steps, whether or not they are actually all used together, as is standard practice in patent apps [tries to mitigate 'but MY implementation omits the step of XORing the bytes with smiley faces, so it's {non-infringing / an improved and seperately patentable process}' defenses during patent disputes?]) "maybe" mask (to where? The great null device in the sky, maybe? I suspect to a different 'channel' as described below) some least significant bits of an 8-bit Bayer pixel value; "maybe" split the raw imager data into "a specified number of channels", this number being a 'nice round number' such that bits from a single data byte can be nicely dealt among the channels; "maybe" subtract byte values from neighboring byte values to produce "an entropy-reduced data model" (that's mathy-marketing speak for SMALLER NUMBERS) ; "maybe" split the resulting SMALL NUMBERS up into a number of separate data streams--assume, for example, in the ideal case, the high nibbles will always be zeros because these are Small Numbers) and compress them separately. Reskimming the application, I can't seem to find where I saw this, but seem to remember it. (Or maybe this is just from me imagining what *I* would do...) ; "maybe" "operate" on each of the channels with a distinct cumulative distribution function; "maybe" multiplex the operated-on channels/streams back together; "maybe" compress the resulting mess(es) using arithmetic compression encoding (sniff sniff, I smell Huffman, LZxx, or similar...although it sounds like true arithmetic coding differs a bit from those). NB: Division in software is (to use a technical engineering term) hella slow, so it will be avoided at all costs. (The app specifically refers to division-free arithmetic coding) The part about masking least significant bits, I have no idea what this is about (then again, I haven't grovelled thru the whole patent application yet). It may be a non-sequitur, or end up doing pretty much the same thing I'm thinking of, but in a different way. So, the 'nugget' here is the assumption that pixel values will tend to remain relatively constant across large stretches of an average image, so only the difference between pixels needs to be stored. (Subtracting blue sky from blue sky yields "not much data" in the blue-sky part of your image). You may also have heard of this scheme under the name "delta compression", a.k.a. "prior art" . Looking at some of the dumps in raw bayer form (open dump in PSP, 8bpp, monochrome) shows the Bayer pattern quite clearly; the alternating light and dark pixels should be evidence enough that subtracting "neighboring" bayer pixels (e.g. greens from blues) will not reduce the data as much as hoped, so I'll go waay out on a narrow limb and assume the first step is to split the data into a red channel, green channel, and blue channel. Now racers, start your difference engines! In the ideal case, subtracting neighboring pixels now will yield small signed numbers most of the time. Sparse little bytes of mostly zeros. Well, with a sign bit flipping around at the beginning, but most of what remains will be zeros. Maybe "high nibble is usually zeros" is a safe assumption - split the data now into 2 streams, "high nibble" and "low nibble", now the "high nibble" stream is zeros, which will compress like a bag of cotton candy. Viola, instant 50% reduction! "But hey, day-drmn space cadet, you forgot about the sign bits!" All right, instead of 2 streams, split the byte into 4 streams--top 2 bits, next 2 bits...lowest 2 bits. Remember, looking for a nice round number of streams that 8 bits will split nicely into. Of course, I don't know of any rule that says the splits have to be equal, you could make a "sign bits stream" of only MSBs, one or more "buncha zeros" streams of the stuff in the middle, and finally the LSB stream where most of the actual image data is now hiding out. 4 streams sounds like a magic number, but 8 streams (all MSBs .. all LSBs) sounds good to me personally. This stuffs most of the entropy into the sign-bit stream (it's even money whether the pixel-next-door will be slightly brighter or dimmer than the one it's being subtracted from) and the last stream (progressively less into the next-to-last, and so on...) It seems like a lot of those streams should cook down to almost nothing in the ideal case. From there there's talk of histograms, this is maybe some variant of standardish LZxx or Huffman coding (who was it smelling zlib?) now that the data is reduced to a sparser form. Or more specifically, that "arithmetic coding" yadda yadda. Take the streams, put data elements into a histogram (*ahem*, dictionary) and see which come up most, assign those the shortest huffman-o-matic codes. In this particular case, one of the 'invention aspects' is that the algorithm will pick the dictionary size (a power of 2) on the fly. 12-21-2004 23:34:09

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile I am currently trying to produce "good" images for analyzing latest patent revelations. Using ForkBoy's Links in Links I can easliy take 25 pictures and download compressed versions. My goal is to get a nice 3 bar - white red blue image. I have achieved some nice red & white bar using a red curtain and white piece of paper. Oddly though the bars must be in verticle direction to show up on lcd, a slight diagonal rotation still yields results but after more than about 15% the lcd image is all white. I have also been able to apply black tape to flash window avoiding complete washout on some shots. There should be an every other line bayer pattern indication and a notable change when crossing veritcle bars. Just a thought but maybe black and white vertilces would work better or even a more formal test chart. 12-27-2004 01:21:45

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile I have a "good" image with a grey/black pinnacle stretching from bottom to one third of the way up. It is only 85kb - a highly compressed white with a slightly blurred pointer. By locating the tip of the pointer in downloaded compressed raw file, I hope someone can decipher compression algorithm. I have zipped the raw, bmp, jpg, png, Thmbnail.tft and placed them in my yahoo briefcase 4 all: http://briefcase.yahoo.com/zqcpwr Click on Pure Digital then Decompression.zip. 12-28-2004 05:08:46

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile brite_eye, Looks mostly good - except the .BMP wouldn't un-ZIP for me??? The RAW file comes directly from the camera FLASH - looks like the other RAW files (though this one has a C8 header instead of a 9C header like most, hmmmm...) How did you get the other images? I'm not asking about your detailed download procedures - that's being hashed out elsewhere - but rather I want to figure out if the image went through any lossy compression stages (i.e. JPEG) in your process between RAW and BMP/PNG. - sailpix 12-28-2004 09:08:42

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile Drmn4ea: Somehow I missed your post when it first went up and didn't get around to reading it until just now. A few thoughts: >"maybe" multiplex the operated-on channels/streams back together; > >"maybe" compress the resulting mess(es) using arithmetic compression > encoding (sniff sniff, I smell Huffman, >LZxx, or similar...although > it sounds like true arithmetic coding differs a bit from those). I'm pretty sure that the order is to break the data into multiple streams, compress each stream separately, and THEN multiplex them back together. The advantage they espouse is that, e.g. 2 histograms having 2^4 = 16 bins will take up a LOT less space than a single histogram having 2^8 = 256 bins. > NB: Division in software is (to use a technical engineering term) > hella slow, so it will be avoided at all costs. (The app specifically > refers to division-free arithmetic coding) The trick here is to make sure that the histogram always has a power-of-2 number of bins, so that the division becomes a simple right-shift operation. > Looking at some of the dumps in raw bayer form (open dump > in PSP, 8bpp, monochrome) shows the Bayer pattern quite clearly; > the alternating light and dark pixels should be evidence > enough that subtracting "neighboring" bayer pixels (e.g. > greens from blues) will not reduce the data as much as hoped, > so I'll go waay out on a narrow limb and assume the first step > is to split the data into a red channel, green channel, and blue > channel. Perhaps you missed the part about subtracting alternate pixels instead of adjacent pixels. That is so say, they propose subtracting even pixels from even pixels and odd pixels from odd pixels. That way, you subtract R pixels from R pixels, G from G, and B from B. Never B from R, etc. > around at the beginning, but most of what remains will be zeros. > Maybe "high nibble is usually zeros" is a safe assumption - split > the data now into 2 streams, "high nibble" and "low nibble", now > the "high nibble" stream is zeros, which will compress like a bag > of cotton candy. Viola, instant 50% reduction! In the patent app, they seemed VERY keen on splitting the 8-bit word into 3 channels, e.g. 3-3-2, or 3-2-3. I think a good first step would be to try to figure out where the histogram data is stored, and how many histograms there are. The size(s) of the histogram(s) will tell us how many channels they split the data into, and how many bits there are per channel. 12-28-2004 09:20:46

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile sailpix, My belief is that during acquire using Irfan (others too), the compressed flash file (85kb for this one) is decompressed to a raw 3.14 MB and then user is given options by Irfan as to desired storage format. If I recall correctly I moved a percent bar up to 100 for jpeg, and was confused by transparency options on png. I wonder if my pictures would look better when properly stored as PNGs. So in short all files are from a raw image with no intervening processing. 12-28-2004 10:07:28

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile sailpix, I uploaded spire_bmp.zip to my briefcase containing just the bmp version, and confirmed a succesful download unzip. 12-28-2004 10:15:08

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Do Fife's 3 channels => 3 pinnacle points? Can someone locate 3 points at spire's top? 12-28-2004 11:03:44

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile The spire_bmp.zip file has a good BMP - looks to be the same as both JPEG and PNG. Wandering through this image it's all white until you hit the pixel @ x=688, y=472 (0-based) where the first pixels for the spire start. There's also some non-white pixels in the bottom left corner, but if we can find the tip of the spire then I hope all else will "fall into place". When I "enhance" your image by turning down the gamma then the non-white pixels start jumping out real quickly. The image data has some blocky areas which look, to my eye, like they've gone through I don't believe that the "histograms" are stored in the RAW image file. From the description it sounds like each histogram is an array of 8-bit numbers which show the frequency of values from some set of previous "channel values". (I say "channel values" since by this point in the process the data has had some low-order bits chopped off via masking, has been subtracted from a neighboring color pixel to reduce entropy and has been split into a 2- or 3-bit channel value. So, it's no longer really an image value, but something much more abstract.) I think the histograms are started with some set of values and then are updated as coding proceeds - the same process can be followed during decoding. The histograms are updated as each value arrives for encoding. The algorithm for this is "described" by Fig. 6, Fig. 8, [0068]-[0076], [0082]-[0085], [0089]-[0094] and Claims 16-26. I think that we can decipher the histogram updating from these pieces. The initial value for each histogram bin is, however, not clearly stated anywhere - it could take some experimentation to match what's being used inside the camera. The other thing which seems to be blatently missing is a clear description of how the three channels of encoded data are multiplexed/demultiplexed. Is it by code? By stream/channel? From looking through the data in each raw file I can't see any clear breaks - it appears to be one long sequence of bits... Also, in Fig. 4 it appears that the whole image is encoded in one long operation without anything like a pause between rows to multiplex the channel streams. This is, IMHO, likely to be the biggest challenge for us to figure out. (And it's vague stuff like this which I believe dooms this as a patent, in it's current form...) Also, has anyone been able to locate the referenced pending patent application dated Oct. 11, 2002 and numbered 60/417,978. I can't find it anywhere. :-\ - sailpix 12-28-2004 15:46:46

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Please review daBass's layouts (Links thread) - I think your histograms might be in the variable length 8 byte segments at the end of compressed file. 12-28-2004 16:24:12

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Based on the patent app. description, there are 3 histograms - one is 4 bytes long (freq. counts for 2-bit channel) and two are 8 bytes long (freq. counts for two 3-bit channels). That is 20 bytes of data (20 bytes = 160 bits, referred to, confusingly, as "160 registers" in [0080]). But, these images have varying amounts of EOF data... all have at least 8 bytes, but some have 32 bytes. That's not consistent with the fixed 20 bytes of histogram data described. Also, I often see an 8-byte EOF data block where every byte is 0. But, a 0 value for a frequency/probablity breaks the arithemetic coding - most algorithms seem to go through pains to specifically avoid 0's. [0074] seems to be where this fact applies to the histograms - they don't let any bin in a histogram drop below the value 1. So, for a couple reasons, I don't think that the EOF data contains the histograms. Hmmm... so what _does_ the EOF data contain? - sailpix 12-28-2004 16:50:52

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile What other types of pictures might help compression decipher process? I was thinking maybe a double pinhole lens to create an isolation white dot in center of imager, or just dropping a piece of black plastic with a vertical slit over the imager through lens holder. Or black film over lens to allow an infrared only photo. I had previously mentioned vertical lines and colored bars - with more successful cameras (latest by Ansel) others should be able to start posting these. While it may seem useless for those with a working camera, better quicker longer lasting success may require this decipher and it is a SMaL favor to request of those with working cameras (you owe it 2 all 4 all). 12-30-2004 07:46:07

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile brite_eye, After thinking about it for a few days, what's described the worst in the patent application is the "channel" multiplexing... so I'm trying to think about what kind of picture would make clear distinctions in the channel values that the patent app describes. If the channels were simply the RGB colors then I could get you to try taking solid red, green, or blue photos. In fact, I wouldn't mind having those around for testing after we figure stuff out. I suppose this could combine into a single picture since our goal would be to ensure that those pure colors are being decompressed and reassembled correctly. For what we suspect of the compression, I think a fade from solid white on one side to solid black on the other side would help me best. This should give constant values for the high channel and changing values for the low channel. The fade must be from left to right - that's important since we need to figger out how the channels are multiplexed for a single row. Slow (i.e. full picture width) fades might be useful, but ideal would be a perfect pixel stairstep left -> right in 256 pixels. I can't sort out in my mind if colored fades would be of any use. Probably not since the color component is more-or-less thrown out by the alternate-sample subtraction and what's left is just magnitudes. So, I need to start with pure white <-> black fades which take color out of the equation and generate a predictable series of light values on the image sensor. In fact, you might have to tint it a bit to get consistent light values from the two sensor colors on the first row. We are challenged by the fact that we don't really have access to the uncompressed Bayer pattern image at any point - that's what we need for testing the RAW data decompression. Instead we have to sorta guess by what we find in the debayerized (and possibly lossily compressed) output images from SMaL's software. But, if we can figure out the compression then we should be able to adjust the rest - I hope. - sailpix 12-30-2004 10:22:39

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile sailpix, you must not have been here during our first hot plug picture downloads which were strictly a 1288x864 raw bayer image. At the beginning of Links thread there are links to 2 of my whites, a cutline black by Drmn4ea, and a white and black by boodle - all hot plugged containing both a raw bayer at $120000 and compressed image at $12000. Perhaps you can make some sense out of the 4 reference bytes for which there are exact pixel values at the end of each FF saturated row. I tried but failed. If I can get a good fade white to black I'll hot plug and give you the raw bayer along with compressed and formatted uncompressed. But until then please examine my/dakotamod's (you probably missed that craziness as well) all whites in Links thread. 12-30-2004 13:14:41

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile You're right - I did come in a bit late. And it is sometimes difficult to pull the pearls of knowledge out of these threads... For example, it took me almost a day to realize that the .RAW format that daBass has mostly documented on his page was actually from 0x12000 in the .RAW files which are downloadble. Ahhh... so we _do_ have the Bayer version of the images - most excellent! That will help greatly. Now we don't really have to guess that we have the de/compression figured out accurately - we'll know. And, since I'm tackling this from the angle of understanding the compression first - I'll have some real data to feed into my theories. No clue on the extra bytes at the end of each line... more mysteries. Do we have a data sheet for the image sensor device - perhaps that has a clue? To simplify stuff - at least for myself - I am going to start renaming these PV2 files on my drive:   .dmp = memory dump (w/compressed @ 0x12000 and Bayer @ 0x120000)   .byr = uncompressed Bayer image (from 0x120000 - always 1112832 bytes long)   .raw = compressed Bayer image w/header (from 0x12000)   .tft = thumbnail (uncompresed) My goal then becomes to convert .raw to .byr - np... - sailpix /) /) 12-30-2004 16:05:29

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Let me know when you are snowed by whites, although I think you might solve it saturated with just those. I pointed out earlier somewhere that on my whites many of the black noise reference bytes were simple 00 02 00 00 and in that case created smaller strings between rows (oddly though strings for like 4 bytes were not identical). With patent in hand it should be "easy"! 12-30-2004 17:19:51

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Another annoyance I have not been able to shake is a possiblity for additional autobrite information that must be applied to the 1288x864 Raw pixel image. That might explain the nonidentical compression of identical edge bytes. Note how much better my downloaded stop sign was then dakotamod's dark original. http://www.photo.net/photodb/photo?photo_id=2964044 by brite_eye http://www.photo.net/photodb/photo?photo_id=2929362 by dakotamod with help from icedragon (where are you icey - I'll bet I can out fly you with my sail iceboard). 12-30-2004 23:15:56

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Has anyone been able to keep pace with morcheeba's work? It would be nice to force a specific raw bayered image through internal compression routine. If so use this thread to discuss best decipherable images - probably starting with an all black having one bit turned on to compare with Drmn4ea's cutline black hole (wonder how his head's feeling this morninginging?) 01-01-2005 07:34:08

RE:Decompression - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Since I have the imager on a Ritz 6410 somewhat denuded already, I'll try severing the data lines out of the sensor and tying them to specific values once I'm back in Boston. This can yield an "all white without reference pixels", plus any arbitrary shades of gray, but I can't do any all red/green/blue or similar, the ASIC is clocking just too darned fast to tie in any semi-intelligent data-stuffer. (Maybe it can be safely underclocked...?) It would be ideal to be able to write the desired raw image to memory and then call the compressor 'manually', but this might be a long way off. The cutline black may be the best bet for recreating/testing the (de)compression scheme as a first step; this will most likely eliminate having to worry about details of the subtraction for now (0 - 0 = always 0, unless it's a PIC core ), dropped/masked bits, and any multiplexing of bits that happens before the arithmetic encoder. Feeding a decoder candidate the compressed stream and having '00000000's returned sounds like a good babystep toward a complete decoder. 01-02-2005 00:56:16

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Drmn4ea, hope you had a great time away from this for a short while. I am waiting for you to place some denuded links in annoying thread. I lost my mind sense and added a Guinness self-portrait nude - mentioning it in my photo.net postings has resulted in editorial deletion of my recent questions (review my recent Legal - 1 2 many 4 all). 01-02-2005 01:48:47

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile I found the following article to be an excellent introduction to arithmetic coding. Has a good mix of theory and practical examples. It even has sample code for compressing/decompressing a sample message. The author assumes a static statistical model for simplicity, but I don't see why it couldn't be modified to be adaptive. BTW - the discussion of "underflow bits" here makes me believe more than ever that the 9-bit "11111110" sequence is the result underflow while enoding the all-white image(s), since that is a situation where there is a large number of consecutive pixels having the same value. http://dogma.net/markn/articles/arith/part1.htm 01-02-2005 06:28:32

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Decompression depression... I've finally written a program where I try to follow the logic laid out in the patent application with diagnostic output all along the way. Despite my best efforts (so far ) I can't get it to replicate the compression that's going on for the PV2 Bayer data. I'll lay out various parts of my thinking - maybe someone can help: + The patent app. documents using every other sample to "reduce entropy". This is a method similar to the "predictor" sample subtraction used in TIFF. The predictor is limited (true?) to use with LZW compression - which is similar, sorta, to arithmetic compression. The data I'm seeing looks like it is going through this alternate sample subtraction. Looking at the first bayer line of a solid white image we see: FF FF FF FF FF... The alternate sample subtraction turns this into: FF FF 00 00 00... And then the compressed version is 55 21 FE FF 7F... which seems consistent since it has some high data (FF's) compressing to low numbers followed by a very long string of zero data (00's) compressing to a very long string of 1's (with a 0 stuffed in every 8 bits - more on this later). So, then I wander over to the cutline all-black where the data is: 00 00 00 00 00... Subtraction gives 00 00 00 00 00. And then, consistent with the previously described compression, a stream of 00 bytes compress to a stream of 1-bits (with stuffed 0's). Sure enough, allblack3.raw shows FE FF 7F BF DF, etc. Consistent again - yay! + A second thing that seems to match up is an arithmetic coding implementation technique called bit-stuffing. This technique is somewhat described in the article that j_tetazoo linked as "underflow bits". There is a clearer (I thought) article describing arithmetic coding named "Arithmetic Coding revealed" at http://www.data-compression.info/Algorithms/AC/ Arithmetic compression is based on coding a sequence of things into a really long and totally unique fraction (i.e. number between 0.0 and 1.0). But, computers don't do fractions that well. So, a fairly standard implementation of arithmetic coding using integers has been developed - a main source on that seems to be a paper by Witten-Neal-Cleary published in Communications of the ACM in June 1987. This algorithm details how to re-scale things repeatedly so that it works using integers. But, there a situation where the algorithm has some trouble - when it finds a sequence which compresses to a long series of 1's in the output. Data being compressed "downstream" could end up needing to flip the whole series of 1's to 0's - very much like adding 1 to 9,999,999,999. Software running with a lot of memory could handle this one way - but "old" (circa 1981) hardware implementations needed a different approach since they didn't have much memory around. Also, it was desirable to find a way to do this with fixed hardware registers. Remember, this is long before megabytes of memory were plentiful like today... The compromise solution was to stick a 0-bit into the output stream every so often to force an end to the sequence. This decreased the compression efficiency a bit, but allowed for coding and decoding with fixed hardware implementations. I think the basic algorithm for this is in patent 4,463,342 and it is also mentioned later in patent 5,418,532 in conjunction with a "guard register" (just like our patent application). So, seeing data compressed to a stream of 1's with a 0 stuffed in after every eight 1-bits is typical output from arithmetic compression that has been implemented in hardware. This is mentioned in section [0097] of the patent app - so it seems to tie together. - But... on the other hand... something looks really wrong for arithmetic compression. When I look at the "edges" of arithmetic compression, I believe that a sequence of 00 bytes should end up compressing to a sequence of 0-bits and a sequence of FF bytes should end up compressing to a sequence of 1-bits. This would also hold true for a 3-bit "channel" like the data byte "channels" described in the patent app: 0 values would compress to 0-bits and 7 values (the highest) would compress to 1-bits. However, I see two things in the compressed PV2 images that contradict my theories. The cutline black image is a series of 00 bytes - but it compresses to all 1-bits. Same with the white images, high value data tends to compress producing 0-bits and low value (i.e. 00 byte) data produces 1-bits. So, there seems to be an inversion from what I'm expecting. I can't figure out where this inversion is taking place. On one hand it could be that the compressed data is just a 1's complement of the actual arithmetic compression output - but that doesn't really work with the bit-stuffing algorithm which is designed to handle a series of 1-bits (i.e. there wouldn't need to be any stuffing if they really were a series of 0-bits...) So, other possible places to invert things are the histogram model or 'most anywhere in between. This is really scrambling my brain. - Arithmetic compression of the sequence FF FF 00 00 00... - using a histogram model following the patent application's apparent intentions - gives me a few 1-bits followed by an endless sequence of 0-bits. The long string of 0-bits doesn't match up to the long string of 1-bits in the PV2 compression. But, worse, the FF FF sequence starting things shouldn't ever compress to anything other than a series of 1-bits - _based on the described histogram model_. - What's the deal with where the compressed data starts in the RAW file? When the header says 9C, the data seems to start at 9D. When the header says C8 the data seems to start at C9. Or does it... is that first byte of 00's part of the compressed image data or not? Bah! So, when I ponder where I'm "off base" in my compression things seem to get out of reach very quickly. The compressed output doesn't seem to possibly match up with the histogram model described in the patent app - so I have to assume that this model isn't being used. So... what model IS being used? It's almost impossible to detect if the data is being compressed directly or broken up into "channels" for some calculations and then "multiplexed" back together for compression as described in the patent app. There are three pieces which are unknown: histogram model algorithms, channel div/multiplex, and compression details. If I had a clear description of any two (or maybe just one) piece then I could figure out the rest. But with this many unknowns I feel lost. I am losing some (not all) hope for figuring out the compression algorithm by following the patent application. I think it's just too vague to be completely useful. The use of bit-stuffing and the patent application are indications that the compression is implemented in hardware. If so, there's little use in combing through the camera's firmware for the compression routine. I know that the bayer image is present in the flash - there, I suspect, for generating the thumbnail - so perhaps there is a decompress in the firmware to get the Bayer from the hardware-compressed RAW data? But, there's definitely a decompress in the TWAIN driver and/or image viewer application provided for the Radio Shack (and other) SMaL-based cameras. I've disassembed the whole FlatFoto TWAIN driver using "PE Explorer", but the decoding routine hasn't jumped out at me yet. Is anyone else looking along this avenue? - sailpix _/) _/) 01-03-2005 00:40:27

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile After succeeding with morcheeba's suggestion on how to "see" his cat, I realized that I could also experiment with reversed decompression testing. By that I mean intelligently changing results of compression and downloading through decompression to confirm intelligence. Anyone think they have the necessary intelligence? morcheeba - do I stand any risk of frying a $79 camera feeding a nonintelligent sequence? Can anyone alter pv2tool to quickly upload modified IMAGE_00nn.RAW files? 01-03-2005 01:24:22

RE:Decompression - 1 2 many 4 all (modified 0 times) morcheeba Profile Good idea! I doubt that you'd hurt your camera brite_eye -- I'm pretty sure the decompression is handled in the windows driver. 01-04-2005 17:13:52

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile OK, I am ready to try some good guesses. sailpix - as many as you can create. others a max of 5. Just post a message in this thread with a link to your good guesses and a brief description of changes. I suggest using highly compressed all whites with slight changes to end of row sequence containing 4 non FF bytes. The hard question is why are identical end of row bytes not compressed identically - perhaps it is a value that must be subtracted from current address to point a previous compression - just repeating the first instance of a specific sequence might also produce an identical result. Give it a try we must start somewhere - my camera is still returnable if it cant take a little abuse. 01-04-2005 18:47:27

RE:Decompression - 1 2 many 4 all (modified 0 times) morcheeba Profile What's the deal with where the compressed data starts in the RAW file? When the header says 9C, the data seems to start at 9D. When the header says C8 the data seems to start at C9. Or does it... is that first byte of 00's part of the compressed image data or not? Bah! I suspect the data starts at 9c -- I found references to this in the firmware. See my memory map @ 152000 and 15209c 01-04-2005 22:28:08

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Well maybe a little luck, I have uploaded 2 all whites that differ only by last 8 bytes. They both decompress to all FF identical images. What is the opposite of a black hole - I forget something like a naked singularity? Maybe just an unstable black hole exploding. I used my blue flatfoto with it set to small 600x800 and 2x zoom. One of those settings must have eliminated the noise reference bytes at end of each row. The C8 header is slightly different and there appears to be more data before and after compressed image - maybe thumbs, but also looks like some autobrite™. After rereading patents again, the ability to vary voltage pixel by pixel may require some kind of difference tables, or as others have suggested I am dreaming and there is no extended software dynamic. Can someone figure out how to put a single non FF byte into compressed image - It would be easy for me to upload then download decompress to verify. Naked Whites http://briefcase.yahoo.com/zqcpwr Click on Pure Digital then decomp.zip. 01-06-2005 01:25:27

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Start with Naked whites above. Then look at these color bands: http://briefcase.yahoo.com/zqcpwr Click on Pure Digital then color.zip. 01-06-2005 07:28:31

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Now if that is not enough (please I need some sleep), tonight I plan to place a small plastic block directly on top of imager for series of whites with a moving black sprite. 01-06-2005 09:33:28

RE:Decompression - 1 2 many 4 all (modified 0 times) j_tetazoo Profile Can I make a request? Could someone figure out how to take a snapshot of "white noise" and post it for download (compressed RAW and non-compressed Bayer versions)? The reason I ask is because I'm convinced that the compression scheme used is "arithmetic coding" as described in the patent app. The tricky part if the way they appear to make use of adaptive histograms for the purpose of calculating the probability of occurrance of a given n-bit symbol. I think what they do is to "seed" the histogram with the assumption that all symbols are equally likely to occur, and then they dynamically modify it from there as the stream of symbols comes in. If I had a white-noise image to work with, I might be able to ignore the adaptive part because all values would start out with a nearly equal probability of occurrance, and remain that way for the whole image. Maybe take a picture of a TV screen showing "snow"? 01-06-2005 09:47:16

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile j_tetazoo, can you provide a PC program to produce white noise on a monitor? 01-06-2005 14:41:21

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile j_tetazoo, after a little more thought we already have black noise photos - all the previous blacks except Drmn4ea's ingenious cutline black hole are amassed with random noise. At the top of Links thread there is a black from boodle that I believe includes both raw bayer and raw compressed images. Do you think this gray-scale chart is worth a shot: http://www.mediacollege.com/video/test-patterns/grayscale.html 01-06-2005 16:01:33

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile I'm pretty sure that "noisy black" (which we have - along with some other noisy colors in recent shots) isn't the same as "white noise". Real "white noise" would jump around somewhat regularly to all intensity levels - after applying whatever LSB masking and the alternate sample subtraction. Hmmm... the alternate sample subtraction makes it harder to visualize. I'm not sure that an actual "white noise" image would give you a consistent frequency set after LSB-dropping and subtraction. I've been pondering what - if any - specific compressed images would help me figure things out. So far I can't quite put my finger on anything specific. I'm going to take another look at whether I can figure a rational path through the compression which includes the 00 byte at 9C - my earlier attempts were starting at 9D since I discounted the 00 byte @ 9C, but I'm beginning to think that it's necessary for a rational decompression. That means that the 55 xx bytes before the stream of 1's start is the transition between 00's (compressed FF's) and FF's (compressed 00's). Also, it's interesting to note - from brite_i's latest color.zip upload - that a string of 00 bytes in the compressed output is allowed without any stuffed-in 1 bits. This is consistent with needing a stuffed 0-bit to break up the possibility where a string of 1's could need arithmetic carrying back to it's start, but a string of 0's won't add up any higher. I'll try to package and post my code experiments - perhaps someone else can stumble on the specific path through the vague ideas presented in the patent app. - sailpix _/) 01-06-2005 18:12:39

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Ok... I posted the programs I've been writing to: http://www.mindspring.com/~rtaylor/pv2.html The main program is CompTest.exe - I've tweaked the algorithm details about a 50-100 different ways without quite getting it right yet. HistTest is another "fun" app since it was designed to let me see exactly what is going on with various histogram updating algorithms which are not-quite described in the patent app. This past weekend I got nowhere near to the compression, but today I approached it with a few new insights and made a bit of progress. (pun intended) Before I was discounting the first byte since it was always 00's which didn't fit my brain's expectations at the time. Today I decided to include it and it seems to help since the FF's at the beginning of an all-white image compress to a string of 0-bits. Also, I counted the approximate length of the first row of data in a .RAW file - right at 98+ bytes. I have noticed that the initial histogram bin value has an effect on the encoding length. So, I played around with values until I got it to compress down to around 90-something bytes by initializing the bins with 16 For the "division free" arithmetic described in the patent app I believe you need to init the bins with a power of 2 - that considerably limits the range of values to try. Things are still a bit (unintended) off since my data doesn't have 0-bits stuffed in to prevent a run of more than eight 1-bits. I think the RAW has around 88 bytes of data after removing stuff bits and I get 93, but I'm in the neighborhood value-wise. A bigger problem is that my compression doesn't seem to work quite the same way in the beginning. I've been testing with white1.byr (included) where the first three data bytes are 00 55 21 before continuing with all 1-bits. The first 1 bit is the 10th bit in the stream, but my compression doesn't throw a 1-bit until the 15th stream bit. I don't know yet if this is due to a histogram value difference, a compression algorithm difference, or something about the camera's strange bit inversion (which I'm trying to match by inverting the output). - sailpix _/) 01-06-2005 23:15:23

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile As promised moving black sprite on saturated white: http://briefcase.yahoo.com/zqcpwr Click on Pure Digital jpeg_sprite.zip - lossless jpg tifbw_hufrle.zip - tif b&w huffman rle (says alot in few words) compraw.zip - IMG_00nn.RAW - compressed raw files starting at index 6 corresponding to 1 above. Wish I had time to analyze and describe, but hopefully _/) from mindspring will spring his mind. 01-07-2005 04:25:26

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile From the top of Decompression thread: Allblack compressed image has 52187 repetitions of 9 bit pattern. 52164 + 23 = 52187 =(23*2269) 23 I can't explain. The same repeating 9 bit pattern can be seen in all whites. I created an all white and all black 1288 by 864 image in Raw Photodesk and saved in lossless jpg format. They both had 4347 repetitions of A2 8A 28. Now 4347*3*3 = 52164 same as above. Odd that both SMaL and jpeg produce the same pattern for a black image as a white image. I am guessing but I think the jump from a 3 byte to a 9 byte repetition has something to do with autobrite extension from 8 bit pixels to 17 bit pixels (SMaL advertises a 500 times dynamic range which would need another 9 bits). The decompression would then need to include a logarithmic adjustment back down to 8 bits (per color 24 total) in the final output. What other reasons can people think of for jump from 3 byte to 9 byte patterns. Are you _/) or (\_ upwind tacking or downwind hacking? 01-07-2005 17:26:54

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Trying to hack, but the wind has died down lately... I added some info to my web pages - basically some binary & hex dumps of the few images where I have both Bayer and compressed ("RAW") data. Page is at: http://www.mindspring.com/~rtaylor/pv2.html I just included the first 12 bytes of each kind of data. Arithmetic coding is a sequential process where each successive bit is interpreted based on the previous bits. So... if I can't figure out an algorithm where the first 12 bytes of Bayer data compress to the first several bytes of SMaL RAW data, then any beyond that is pointless. Actually, the same concept applies to the first bytes, so I'm being sorta forward looking by dumping a whole 12 bytes. Note that the RAW data probably covers more than the 12 bytes of Bayer data. The 12 bytes of RAW data may represent more (or less) than 12 bytes of Bayer data. Sometimes compression algorithms don't work real well for a specific sequence of data and actually create a longer string when it's compressed - but they should be designed to actually produce a smaller set of data when used for a complete input data stream. I've been reading arithmetic compression literature - mainly patents - trying to figure out if there's something I can be doing differently in compression. The algorithms I've combined in CompTest seem to compress a row of white data by an amount similar to the camera. The camera compresses one row (1288 bytes) to around 108 bytes and my algorithm can get 106 bytes with some tweaking that doesn't match the patent application. However, my compression of the "stop" image seems much worse than the camera. Directions to experiment: - Test applying subtraction algorithm to first two Bayer bytes where each would be subtracted from zero. This might be able to match the compressed data (i.e. 55 21) at the beginning. - Change encoding algorithm to more closely match the source code published in Witten-Neal-Cleary's seminal June 1987 CACM article. They did a couple things "backwards" and perhaps following their logic will more closely match the backwards stuff I see in the camera's compression. - Check code I wrote to generate cumulative frequency counts (i.e. high_count and low_count). Did I goof up something here? - Add logic to either a) un bit-stuff the raw data or b) bit-stuff my output. This'll let me compare my compression output more directly to camera data. OTOH, I'd rather work this into my algorithm where it "should" be... - Extend code to run my compression on the full image of Bayer data. With bit-stuffing algorithms added I could then compare the length of my output to the camera's compressed data length. This may help me tune/establish histogram initial bin values - they seem to affect compressed output length directly. - And, of course, dig through the TWAIN driver and .EXE supplied for SMaL reuable cameras to find the decompression routines there. This is a "find the needle in a haystack" task, but I know it's there. - sailpix _/) 01-11-2005 22:39:28

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile _/) Please do not discount a possibility that the Raw FFs and 00s may not be actual extended dynamic values. There may be a separate application of invisible autobrite™ confusing all attempts to decipher. 01-11-2005 22:48:27

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile I have asked taytrr & sailpix to collaborate on decompression blues. There names differ by only 1 character - in my message below taytrr is k and sailpix is h. k, I doubt they have different imagers; they definitely do not have two "completely" different compression algorithms - blue flatfoto (T29-6620) easily decompresses photos from all other cameras! The change from 2F to 30 is probably very minor (could be just a bug fix), but even 2F may have some significant differences - there have been failures with 2F and no successes. I now have a 2F, but need clear-headed cautious time before I accidentally fry it, which may not be for a while. Please try to collaborate with sailpix on decompression thread - your experience along with some hot plugged dumps may help decipher effort. h & k, I hope you can work something out. k I have blind copied h. h as captain please respond to k with some "Hoist the Sails" orders. k please then respond "Aye Aye Sir" to h. Now I leave to lee for hopefully some R&R (rest and recuperation, or ?). 01-16-2005 16:46:55

RE:Decompression - 1 2 many 4 all (modified 0 times) mike Profile | Email BLUE IMAGES... I changed pid on a CVS BLUE to 29 modified lens for macro was using photobase ,,,everything going fine.. decided to use irfanview....got BLUE Background/black images... Then it dawned on me that irfanview showed unknown camera.......I had selected FOXZ instead of FLatfoto I will try this with photobase...to see if results are same,,, i suspect so... 01-16-2005 18:18:03

RE:Decompression - 1 2 many 4 all (modified 0 times) mike Profile | Email BLUE IMAGES... I changed pid on a CVS BLUE to 29 modified lens for macro was using photobase ,,,everything going fine.. decided to use irfanview....got BLUE Background/black images... Then it dawned on me that irfanview showed unknown camera.......I had selected FOXZ instead of FLatfoto I will try this with photobase...to see if results are same,,, i suspect so... 01-16-2005 18:18:20

RE:Decompression - 1 2 many 4 all (modified 0 times) mike Profile | Email BLUE IMAGES CVS BLUE 6520 with pid set to 29 Photobase extracts blue image when using Foxz2 ...extracts fine with FLATFOTO .....he who had the type 30 might try changing to type 24...it is easy enough to do with pv2tool204...... 01-16-2005 18:36:58

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile I'm on the trail of clues about the compression - I think... It took me a week or so to make a USB cable for my camera. Today I grabbed the various software and started hacking. I've gathered a small collection of driver software for these cameras. There seem to be two main versions: the old STI drivers (FlatFoto, OS6628, and Fuji eyePlate) and the new WIA driver set (Che-ez). I'm not sure what Creative and Logitech drivers look like since I can't easily crack open their install packages (and I don't want to experiment by installing them....) I have a Wolf/Ritz Red 6410 PV2 camera. I installed the Che-ez Foxz2 drivers. The latest PV2Tool (v2.05) didn't work for me - wouldn't unlock this camera. Fortunately PV2Tool v2.04 works fine - I can repeatedly download the pix I have in my camera. v2.05 wouldn't unlock my camera - but it would list and download RAW files just fine. For now, just downloading stuff was my goal - since I want to find and understand the de-compression routine. It took me a while to find where the active code was. The cheezFozxTwain.ds driver has a LOT of code in it - about 17Mb of text when disassembled! - much of which seems to be designed to for writing multiple file formats (JPG, PNG, BMP, TIFF, PCX, etc...). Then there's the U-I code - which I also didn't want to mess with since I expect it's isolated from most the decompress stuff. Also, lots of the TWAIN driver seems to be various data areas. It's a big ocean to sail through. From looking at a disassembly, most of what I could quickly identify was the error messages. However, since I have things working correctly... setting a breakpoint on one of the errors wasn't gonna get me stopped in the code. Also, since I we're not 100% certain about the compression details, it's hard to know if a specific error string is associated with the SMaL .RAW process or a similar compression in libtiff or libjpeg or something. I finally got a breakpoint to work by setting it right before the code which formats the image download progress string (ex. "0001/0004"). This finally confirmed that I could set breakpoints and the code in memory exactly corresponds to what I am seeing in the disassembly by PE Explorer. Then I found a section which uses the string "smaltmp.jpg" - perhaps it has some feature to write this jpg file for each image. This breakpoint got hit once at the end of each image - closer, but still not there. Also it seems to skip writing this temp JPG file... whatever. Then I set a breakpoint at offset 0x100BA3E0 - jackpot!! This is right before some strings about "borders" and "dropped bits" - it gets called shortly after the U-I shows each new image being processed. From looking around a bit I noticed that the EBX register was pointing to memory containing the 1st RAW file from the camera - bingo. I hope this is at the point where it has just recieved the RAW and somewhere before decompression starts. I traced through the code for a while. The code following my breakpoing proceeded to access various fields in the RAW file header and then usually calls another routine with each value. I'm not sure of the purpose of the routine being called - but it seems to have logic to log/print/something an error string after each value. A bit more studying of this (matched with what daBass already figured out) should give me a much better map of what's in the header. Look for a report on this in the next couple days. Where it goes from there is confusing. Reading assembly language is like walking through a forest looking only through a telescope. With a bit of thought (and perhaps watching it in action) I can figure out what some code parts are doing - but any larger picture is tough. I stepped a bit further and I started seeing some repetitive looping with occasional references to the compressed image data, 508h (1288), 360h (864), and 10FB00h (1288x864) - but nothing that's obviously the decompress loop. There's a chance that the decompress happened before my key breakpoint. I've also been looking for somewhere that it feeds uncompressed output size (10FB00h) to a call into the free() method in the run time library. Plans for my next session are to make a better layout of the .RAW file header and then to look through some annotated assembly language. I may be able to start editing the assembly language so that it becomes more readable. - sailpix _/) 01-24-2005 00:17:27

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Ok... I followed up on the header analysis and here's what I now (think I) know about the RAW file header:   http://www.mindspring.com/~rtaylor/PV2/RAW_File_Header.htm There are a number of new fields to figure out - I'll probably finish my header dump utility next so I can get data from a collection of .RAW files for easy analysis. Initial thoughts: * The INTERPBORDERxxx fields seem to be part of specifying how the CMOS image sensor is larger than the resulting image. This makes sense to me - I assume the Bayer -> RGB image algorithm involves interpolation and having extra pixels around the edge would be necessary for interpolating to get the image edge pixels. * The "TopBinCount" value is of interest to me since the histogram algorithms in the patent application are described using the word "bin" for each histogram entry. From looking at a couple .RAW files I see the values 7F and 00 in this field - not what I'd expect... * The code I analyzed appears to handle accessing data from at least three different header formats. At the beginning there is a main branch taken if the header format is 08 or 09, then the following area of code skips processing some fields (noted in struct) unless the header version is 09. All headers that I have seen are "09". I haven't analyzed the other fork of the main branch (i.e. header not 8 or 9) - but we could follow that path if a different .RAW header shows up. That's all for now... I can follow the code to try to understand specific field handling - if requested. But, I'll probably start looking to identify the decompression routines next. - sailpix _/) 01-25-2005 12:30:15

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Just a minor note - new CVS cameras have C8 instead of 9C for header size, but are still type 09. 01-25-2005 15:04:38

RE:Decompression - 1 2 many 4 all (modified 0 times) Chronos Profile A quick note: the Macintosh OS X version of the FlatFoto drivers, is compiled WITH symbols..... (and a sloppy installer, CVS pointers, a few file paths, the developers' user id, etc.) _SP_ReadHDRPixelBayerColorPlanes sounds like fun. 01-31-2005 19:36:45

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Ok... my tracing of "smalraw" decompression has moved forward a bit. Not all answers are in, but here are a few things I've learned. 1) The first byte of image data (i.e. the byte at 9C or C8) is just skipped. This seems to be consistent for all possible variations of decompression. I believe I saw one .RAW file where there was a non-00 byte here, but all the .RAWs from my camera (and most others posted here) have 0x00 for this byte of data. 2) There are 3 CDF/histogram structures setup - just as described in the patent app. The first two have 8 bins (i.e. 3-bit symbol values) and the 3rd has 4 bins (i.e. for 2-bit symbol values) 3) CDF value initialization is non-straightforward. All the patent app says is that the bins are "initialized" before being used - I knew that was too simplistic... I tried a wide range of approaches with initializing the bins to a constant value - nothing would produce the compression sequences that I see in the .RAW file. For the first .RAW file on my camera, the CDFs are being initialized to 1st & 2nd CDF (3-bit): 3F 37 2F 27 1F 17 0F 07 3rd CDF (2-bit): 3F 2F 1F 0F The bin-init routine starts from a constant value - 3Fh in the cases I've traced - and then steps down evenly for the number of bins being initialized. 3F is calculated in another place from (I believe) a hardcoded value of 06h. I traced through the low-level assembly language steps for 06h -> 3Fh, but I'll need to take a few more passes through that code to a) check whether any other values/inputs figure into the result and b) try to see the higher-level algorithm involved. 4) I've identified a number of other routines in the decompression - but several more passes will be needed to trace through the exact details. Here are the areas I haven't fleshed out into complete detail yet: Lookup_CDF() - looks up value in CDF, may also need additional compressed data input Update_CDF() - updates CDF bins and pointers with new symbol. I expect this to match up with the poor descriptions in the patent app, but the details await an hour or so of my time. Arith_Encode() - I found code which I thought was just another initialization routine, but after seeing it being used during the main decompress I'm realizing it may be the main arithmetic compression decode. This will make complete sense if I can fit some of the calculations into the range shifting technique frequently used to implement AC. Main decompress/multiplex routine: I've found this, but everything seems to be mixed up together. I sorta expected that. However, it means longer to really figure things out... Prognosis: Considering my current rate of progress and other things in my life which shouldn't be ignored... 2-3 weeks and I'll have everything nailed down. I'll have the basics much sooner than that - but when you're compressing bits, each one matters. Looking forward: a) Once we have the raw Bayer image data, then we'll need an algorithm to demosaic this into nice RGB pixels. There's a "bilinear" algorithm which seems to be something of a standard - but it can have chromatic abberations in it's output that are similar to what "Ansel_Adams" saw in some images. So, we may be able to do better than SMaL by using a different algorithm here. However, this gets into another area of fairly intense image processing. Googling for the words "demosaic algorithm bayer" turns up a bunch of academic paper leads around this type of process. b) One way to avoid doing our own Bayer image processing would be to just format the smalraw data into Adobe's new "Digital Negative" format. This is basically a TIFF file with raw Bayer data as the data. Then, Adobe Photoshop will read the Digital Negative file and do lovely conversions (I'm sure ). Here's info on the Digital Negative format: http://www.adobe.com/products/dng/main.html However, Photoshop isn't "cheap" - and providing an expensive path as the only way to process image data is definitely "at odds" with our goal of ultra-cheap digital photography. Maybe there are some current open-source projects (gphoto? gimp? etc...) which have this image processing handled already. c) Finally, I've been thinking about what I should do with the details of the smalraw image compression. One approach is that I just post a detailed-enough high-level description of the compression process - i.e. a description of what that kind of black box would do. Then someone else (i.e. not me) writes a code to decompress the smallraw image data. The goal here that the details of SMaL's code (which we don't want to misappropriate) stay disconnected from code written to process the images on the cameras we have bought. This idea may have been more appropriate in the "Legal -..." thread, but also fits here. - sailpix _/) 02-02-2005 10:54:36

RE:Decompression - 1 2 many 4 all (modified 0 times) morcheeba Profile great work, sailpix! 02-02-2005 11:11:46

RE:Decompression - 1 2 many 4 all (modified 0 times) Chronos Profile Other applications are starting to support DNG -- see the "user to user forums" on adobe's web site, there's a DNG forum with more details. But, reading the DNG spec, I don't think it supports HDR like data (which is what SMaL claims their sensor does). If you could format the image as 16 bit integer data, then I think DNG could handle it. 02-02-2005 23:26:46

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile Hello all. I've been really busy, and haven't had the time to play recently. I found a great hex/editor image viewer. They have a free trial. Its called AXE and you can get it here http://www.jbrowse.com/products/axe/ I found it and I though about the smal right away. 02-14-2005 16:49:06

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile I've put a few more hours into deciphering the TWAIN driver... Relative to my notes on 2/2, the CDFs are initialized as I mentioned before. The 3Fh top value is the 2^6 - 1 where they hard-coded the 6. So, the CDF values I found are what we can expect for each image. CDF_Lookup() and Update_CDF() have turned out really weird. Occasionally a flash of insight gels together a bunch of assembly code, but there are still significant stretches in these routines that I'm not sure of. My brain doesn't have a status flags register, alas. I'll keep hacking at it. Probably the biggest news flash is that I have developed the theory that the EOF data is information for decoding a series of images from a single RAW file. There are a couple directions this could go. They might use this format for a long series of images - i.e. a movie. But, more likely, they have some cameras where the CMOS sensor somehow dumps out separate images for red, green and blue. This fits with the strange blue images which people decode sometimes... The main RAW header provides enough info to find and decode the first image - but getting to the additional images involves navigating through the EOF stuff. If the first image is the blue plane and if older drivers don't know how to follow EOF to the red & green plane images then this all makes sense (sorta - it's a slightly strange format for things...) If the Cheez Foxz2 driver - which I'm tracing - has the right EOF logic then I think I can figure it out. BTW, the Foxz2 is a 2MP camera - like the FlatFoto 2MP. Do the Foxz2 drivers successfully convert images which would otherwise require the hard-to-get FlatFoto2 drivers? - sailpix _/) 02-15-2005 00:38:05

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile Foxz2 does not work for 2F or 30 cameras - not sure I understand last question. 02-15-2005 01:51:39

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile I'm still making progress on compression decode. CDFs are clear, the rest of the process just awaits my time. I wouldn't call it "patented" quite yet... If the patent application had the same clarity as a decoded image I might bestow it with "patent pending". I have found a possible solution to the Bayer -> RGB conversion here: http://www.cybercom.net/~dcoffin/dcraw/ This is an open-source program which will convert the RAW Bayer formats from a bunch of digital cameras into a generic image format (PPM). It has incorporated the some of the best demosaicing algorithms already - there are sites which compare it favorably to the RAW processing shipped by camera vendors. I think some of its logic is incorporated into IrFanView already. So, my plan is to give it a look once I have .RAW -> Bayer done. It would be fun to end up being able to process SMaL camera images better than CVS... I grabbed FlatFoto 2 drivers. If I can get a working disassembler (min have all expired ) then I'll take a peek and see how close it is to the Che-ez Foxz2 driver that I've been trying to mind meld. 02-23-2005 21:14:23

RE:Decompression - 1 2 many 4 all (modified 0 times) brite_eye Profile sailpix, just a suggestion for when you have time - creating another instance of operating system is quite easy and then you are entitled to a complete new set of expirations! Just google for: multiple-boot xp. I have yet to find a product that actually checks CPUID or network ids to disable continued reinstallation and use. 02-23-2005 21:39:12

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Not a problem ...yet. I haven't run out of fresh machines to play with. I'll just install the disassembler on another system for now. Slight stall in that process though. I generally pull the driver files out of the install using InstallShield's ISCabVu utility. This lets me just grab a file without going through the install itself - and I never get the option of seeing a EULA, if the install would have shown me that. I have InstallShield v6.x version of this utility - it has opened almost all of the SMaL camera driver installs so far (except for Creative Labs, who rebuilt their own install using the WISE product). The FlatFoto 2 driver install is built with InstallShield 7.x - and my old utility will not open it. I also found Che-ez Foxz3 drivers posted last night - on their Japanese downloads page. They aren't present on English downloads page - maybe the product isn't being marketed to any English-language markets? This driver was built with the latest InstallShield 10.x system. So, I need to get the ISCabVu utility from InstallShield 10.x to proceed. That shouldn't be too hard to find - I think I can download a limited time trial version of InstallShield 10.x from their website. - sailpix _/) 02-24-2005 08:58:53

RE:Decompression - 1 2 many 4 all (modified 0 times) billw Profile Anybody else try out the new Flatfoto2 driver listed in LINKS? I tried it out but it doesn't appear to have the TWAIN component that I assume the original Flatfoto2 driver CD has. Nothing shows up in C:\Winnt\twain_32 after install. I'm singing the blues with my T30-6520. 02-24-2005 10:33:01

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile From studying the cheezFoxzTwain.ds driver I now have some code which can successfully decompress the data in some RAW files giving me the raw Bayer sensor data. This took a good bit longer than I expected. Originally I wanted to understand everything at a "high" level so I could write a decoder from scratch - but that didn't come together the way I originally wanted. I say "some" since I've discovered that some images are stored in (I think) segments. This is what the EOF data is all about - it is a table of the pieces for the image. When my code is run on a multi-segment image then everything is decoded correctly for the first segment - then things go wrong. I had noticed that the EOF data handling logic in the Foxz2 TWAIN driver would do multiple decodes - I assumed that was for a file that had multiple images, but it appears to be for a "multi-segment" image. Now I'll have to go back and really understand how the EOF stuff works - shouldn't take too long... I've been talking with Forkboy a bit and I mentioned the concept of adding a feature (to PV2Tool, I guess) to upload an arbitrary .RAW file to a camera. My original idea there was to be able study the TWAIN driver's decoding (which reads from the camera) of any .RAW file - still a useful tool for debugging. But I think this approach could help us do testing to understand the various SMaL image processing mechanisms. For starters I'd like to take a .RAW image which reads with "blue hue" (unless processed FlatFoto2 driver) into a different camera - some testing could let us figure out if the blues are from something in the camera (i.e. in the .RAW file) or from something in the driver. Once I finish handling multi-segements we'll have Bayer output from a .RAW file - then it's time to start playing with image processing. - sailpix _/) 03-09-2005 14:42:27

RE:Decompression - 1 2 many 4 all (modified 0 times) Drmn4ea Profile @Sailpix, congrats! Everyone hang onto your 'fried' cams; I'm working out a custom microcontroller interface to SMaL's CMOS sensor. (Reading what looks like repetitive garbage data out of it so far, but will keep (w)hakcing at it). Then to tackle the LCDs when I can get some boards made. 03-10-2005 13:00:36

RE:Decompression - 1 2 many 4 all (modified 0 times) Mehoff Profile Don't know if this will help the decompression/image processing cause, but here goes. I took a picture this morning with a CVS Blue 6510-T28 and downloaded the raw image with PV2Tool. Downloaded the picture with IrfanView/Foxz but did not delete from the camera. Then downloaded again with Irfanview/FlatFoto2 combo. Sorry if this was a waste of time. http://mysite.verizon.net/vze6sg4z/CheezFoxz-07.jpg http://mysite.verizon.net/vze6sg4z/FlatFoto2-07.jpg http://mysite.verizon.net/vze6sg4z/IMG_0007.RAW 03-12-2005 18:50:18

RE:Decompression - 1 2 many 4 all (modified 0 times) teslafreak Profile | Email wow ive got to order me flatfoto drivers the sharpness is better along with definition it looks like ifranview.s raw to jpeg converter is throwing away a lot of detail (and i thought the fuzzy trees was just my camera) my email thoughtpoliceusa@yahoo.com arrrrgh 03-12-2005 19:26:01

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Thanks Mehoff! That was just the sequence I was gonna suggest after you posted pix on the Photos thread. For a better comparison you could take the lossy compression of JPEG out of the picture (pun intended) by saving to TIFF, PNG or another lossless image format. The difference - I'm convinced - is in the image processing part of the FlatFoto2 drivers, not the camera or IrfanView (note that both pix were downloaded using IrfanVw, teslafreak...). I guess that the FF2 drivers just have "better stuff" from SMaL. Perhaps we can get similar (or better?) results by decompressing the .RAW and "processing" it our selves - which I'm working on. - sailpix _/) 03-12-2005 23:58:06

RE:Decompression - 1 2 many 4 all (modified 0 times) Mehoff Profile I repeated the same sequence (using same camera) as above except saved as uncompressed .tif this time. Unfortunately my puny free Verizon web space doesn’t have the room. Anyone wish to plump-up (~6.75MB) their site? If so, give me an address and I will email the three files. By the way, sorry for the repeating sunrise theme. I must be stuck in early mode lately. 03-13-2005 06:59:25

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Yikes - "uncompressed" is so, um, big! I suggest TIFF with LZW compression - or PNG. Either of those compression mechanisms is lossless and doesn't change the original image that IrfanView retrieved from the camera. - sailpix _/) 03-13-2005 07:58:59

RE:Decompression - 1 2 many 4 all (modified 0 times) Mehoff Profile sailpix, tried tiff with lzw. Reduced size of the CheezFoxz by 37% but only 3% for the FlatFoto2 (interesting?). Still too plump for me. Does compressing with WinZip change the original images? That gets the total size down to <4MB and that I can do. 03-13-2005 08:51:01

RE:Decompression - 1 2 many 4 all (modified 0 times) teslafreak Profile | Email youre right sailpix i should have said the cheez criver vs the flat foto driver ive used ifranview with the jpeg quality set to 100 and compared photos with ifranview set to tiff and the image still looks like the edges have been softened flatfoto must have better image processing in there driver but raw should be raw right? no matter if its taken off with cheez or flatfoto? THAT IS THE QUESTION! 03-13-2005 08:55:58

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Yes, the RAW files are the same regardless of which driver is used. It _does_ make sense that the Che-ez Foxz2 driver picture compresses better than the FlatFoto 2 driver picture. Compression doesn't work as well when there is more variation/detail in the picture - and the FF2 pic definitely has more detail. The FXZ2 pics look blurred next to FF2 pix. ZIP is lossless - nothing is changed when any file (picture or other) is compressed to & from ZIP format. You might find that WinZIP works better on the uncompressed TIFF image than LZW TIFF, so try both. - sailpix _/) 03-13-2005 18:00:41

RE:Decompression - 1 2 many 4 all (modified 0 times) Steveo Profile Has anyone looked at this? http://www.aim-dtp.net/aim/digicam/dcraw/ I'm just woundering if the flatphoto2 is using some version? 03-13-2005 20:47:21

RE:Decompression - 1 2 many 4 all (modified 0 times) Mehoff Profile sailpix, here is a link to the zip file with the two driver comparison images and the raw image file. The two pictures are uncompressed tif. http://mysite.verizon.net/vze6sg4z/Driver-Comparison.zip 03-13-2005 21:06:22

RE:Decompression - 1 2 many 4 all (modified 0 times) teslafreak Profile | Email ~9 overdriven pixels with the flatfoto driver vs ~27 overdriven pixels with the cheez foxz driver ps went to radio shack to order the flat foto driver cd and they said they couldent order the part will try the number tommrrow but i hope there not out of stock tslafreak email thoughtpoliceusa@yahoo.com 03-13-2005 22:35:58

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Whoa... I have entered a zone of pleasant surrealness after my old school - Bucknell (#14 seed) - beat Kansas (#3 seed) in the NCAA Mens Hoops tournament. My sisters went to Duke and UNC where it's amazing if they _don't_ win in the 1st round. I finally get to play! DECOMPRESSION PROGRESS REPORT Summary: Not done yet... sigh... The program I'm writing right now loads a .RAW file, dumps out header information, decompresses the image to a memory buffer and then, if it can, compares my decompressed data to a .BYR file. This _almost_ works completely for several files. The problem is that the last 4/6/8 bytes of the file come out wrong. I'll dig into debugging this next since it may be helping cause the next problem. For a couple files I get some large areas of incorrect data in the middle of the file. Sometimes this continues to the end of the file. So, something else is wrong. Time last weekend and a couple hours each night this week went into sorting out and reproducing the multi-segment decompression details. When an image is broken up into multiple segments (as listed in the EOF data) then you have to decompress each segment separately. Then there's some extra processing between segments that I can't clearly describe yet - sometimes it copies previous data, sometimes it fills with 0xFF bytes, sometimes it does nothing. I figured out a way to extract the decompressed Bayer image data from the running Foxz2 TWAIN driver. I can use Visual Studio to set a breakpoint after the RAW data is decoded and then save a "minidump w/heap" that creates a huge file. The decompressed image is in the dump file - but I have to search for it using the first several bytes of image data written down at the breakpoint. When I find the image in the dump file I can edit it to produce a .BYR file for comparison to decompressed .RAW. I have decided that after it works I'll extend the code to wrap the Bayer data into an Adobe Digital Negative (.DNG) file. DNG is a variation of TIFF which can directly hold the Bayer data + other header information. .DNG is supported by PhotoShop, the free DCRAW code, and some other applications - I expect DNG support in more applications someday, especially any that are supporting RAW digicam data now (like IrfanView). I'm tired of missing my own predictions for when I'll have finished code... I'll keep working and it'll be done when it works. Go Bison! - sailpix _/) 03-19-2005 09:56:33

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Ok, so Bucknell in the NCAA tourney didn't last long... It was fun while it lasted! :-\ DECOMPRESSION PROGRESS REPORT: I figured out - sorta - what was going on around the various lengths of data at the end of my decompressed Bayer data which didn't match the original (or Foxz2) Bayer data. The Foxz2 Twain driver is actually reading past the end of the valid image during the decode. The first 8 bytes of EOF/Segment Table data is always zeros (0x00 bytes). I fixed it to "perfectly" decompress a couple more of my test images by making sure that I fed 0-bits into the decoder when it got past the end of the image. But, this still left some images which didn't decode right... Further investigation found that after decoding the Segment Table data to create the Bayer image... the driver decodes on into whatever is left in memory beyond the end of the freakin' file! In my case, this meant that after the end of image data for IMG_0013.RAW it decodes into the EOF data (8 0x00 bytes in this case, a single-segment image) then decoded on into data left in memory from IMG_0012.RAW (which was longer than IMG_0013). So, I can make sure to read the EOF Segment Table into memory for this use in decoding each image, but beyond that there's no rational way that I can simulate any data which would be left over from the last image which was longer than the current image. Also, I figure this data isn't really important since there's no logical way that this data would be present in the camera for the encode process either. This is sorta crazy. Since there is only a 2-row interpolation border on the bottom of the image I figured that the Bayer demosaicing interpolation would be using this data. But, if there was garbage in the last several bytes of the last line of data and it's used to build the final image, this would show up as strange pixels at the bottom-right edge of the resulting image. (Anyone seen that?) So, I almost have to assume that these last bytes of the last line just aren't really used - or maybe the whole last row isn't used. That's a bit disappointing since it also means that the last bytes of the last line of CMOS sensor data isn't preserved by the camera's compression mechanism. I hope our future work at processing the Bayer data into an image determines that this data wasn't needed after all - or at least won't be missed. Now I'm left with one (I hope) problem which appears to be with the inter-segment image processing for a multi-segment image. This is an area I haven't traced thoroughly, so a bug there won't offend me much. - sailpix _/) 03-21-2005 22:21:59

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile PROGRESS REPORT: I've been hacking at this for a few hours on each of most nites... Progress _is_ occuring, but it may need to slow down a bit since I'm about to get married and I'm getting a steady stream of "you need to do..." around the upcoming wedding. After chasing down several bugs that I had left, I reached a point on the evening of 3/25 where I could successfully decode all of a collection of images that I've taken with my camera. At that point I'd taken 26 pictures with my camera - but I can only check output for the 15 images where I've gone through the process to save the Foxz2 driver's decompressed Bayer data. So, it looked pretty good. However, running the code against the set of images from other folks where I have Bayer data (i.e. stop, sunnycad, white1, white2, dakatawhite/black, eyechart) showed a bunch of errors. Close, but not quite. I could rationalize it away (or just put it aside for later work) if the errors were a few bytes at the end - but at least one image (sunnycad) shows several small error ranges right in the middle. I haven't figured out any mechanism for uploading these older images to my camera yet. First, I just don't want to take that chance with my one camera until I've exhausted other approaches. Second, the tool mentioned for that (WinImage) is a 30-day trial, so I'll want a plan before entering that limited time period. So, I cleared out my camera and took some more pictures yesterday (3/26) - this time of my sailboat. I was hoping that at least one picture would have an error in my decode program that is similar to the problems I'm seeing in sunnycad, et. al. Last night I "developed" the images by a) downloading the .RAW files; b) running the driver with a breakpoint after the main decompress routine and for each image stop I dump the memory to a file and write down the first few bytes of the image; and c) trim each dump file to just the Bayer image data by finding the data start and trimming to 0x10FB00 length. Then I run my application which decodes each .RAW file and compares the data to the Bayer (.BYR) data. Yep, I got errors... but not the same errors that I'm seeing in others' .RAW data... :-\ Four of the 7 pictures I took have the SMALKEY_IMGR_ROWMASK value set to something other than 0 - and the decode comes out "all wrong" for these pix. Three of the images had 0x55 for this header value - these images crash my decoder since the decode goes long past the end of the input buffer looking for data. One image had 0x01 for this value - it decoded, but decode errors start at the 3rd byte of output data. All of the others' images I'm using have 0x00 for this value - in fact, all images I've taken with my camera have 0x00 for this value. Most of the pix I've taken were indoors, this new set was outdoors - perhaps there is something about the different level of light which triggers the camera to modify the .RAW compression? Or, perhaps this is where they mask off the low-bits to get better compression - this is described in SMaL's patent application, but I haven't seen it anywhere in the Foxz2 code so far. I had identified a couple areas of the Foxz2 driver code that process this header value, however my code just implements what happens when this value is 0x00. I thought (hopefully) that this value only was set by some other model of SMaL-based camera - wrong! Darn... Now I need to go back and add the IMGR_ROWMASK handling to my decode. The one area that's mixed in with my current logic seems to be a different predictor mechanism. When IMGR_ROWMASK is 0x00 the Foxz2 decode uses the alternate sample differencing predictor described in the patent application - now we're heading off that map into something different. The other thing I noticed is that after the main Foxz2 decode (which I've been working to match), there is another routine which is called if IMGR_ROWMASK != 0. I'll have to get some dumps of the Bayer data after this routine to see if I can figure out whether I need to replicate that processing too. The expanded predictor code shouldn't take me too long to implement - should be done within a week. However, the additional routine they're calling is sorta large and will take a while to sort through. Sigh... every time I think I'm near the end. Before I even discovered the errors I had noticed that the data for these 4 non-0 rowmask images had a different trend. When I'm looking at the Bayer data for an image I usually see data like this: A1 B1 A2 B2 A3 B3 A4 B4 ... where A1/2/3/4/etc are all similar values and B1/2/3/4/etc. are all similar/close values. However, for these new images, the values looked like this: A1 B1 A1 B1 A2 B2 A2 B2 A3 B3 A3 B3 ... where the first pair (A1 B1) was repeated, then the second pair of values (A2 B2) was repeated. I only noticed this for the first 8-10 values which I wrote down during my processing, but I'll open up the files again to see if this pattern persists throughout the file. This looked a bit disturbing to me since it is clearly less data from the original sensor image. But, on the other hand, maybe it explains the blockiness which I saw when zooming in on some of brite_eye's old b/w pictures - I'll have to go back and look at those again. ----------------- If there are any other programmers lurking with an inclination to help... you could help me by coding my "next steps" which are constantly getting postponed as I discover and fix decompression issues. What I need to do next is to package the Bayer data into an Adobe Digital Negative (.DNG) file. This will let me a) load the image straight into Adobe PhotoShop and b) convert the image using DCRAW. Actually, the Adobe PhotoShop route is becoming important since I may need that to see what's getting done to the Bayer data by the extra routine called when rowmask!=0. So, I need a Bayer (.BYR) -> DNG program. If nobody writes this quickly then I'll get to it in a week or so. Basic work is: - Download & print DNG file format - Read through DNG doc to identify what header tags need to be created for minimal DNG. - Identify headers which would be useful to hold metadata from SMaL RAW file - Write console app (C or C++ run-time library calls only) to package .BYR file (data) + .RAW file (header metadata) -> to .DNG file Drop me an email soon if you have the skills, tools, time and inclination to write this. - sailpix _/) 03-26-2005 10:40:13

RE:Decompression - 1 2 many 4 all (modified 0 times) tapostrophemo Profile sailpix, That's a nice idea to create a BYR->DNG converter. However, what's the spec for a *.byr file? t'mo 03-26-2005 22:22:44

RE:Decompression - 1 2 many 4 all (modified 0 times) sailpix Profile Good question... I am using .BYR files to store the simple, raw, decompressed CMOS sensor data - the data resulting from decoding image data in a .RAW file. These files are my "own invention" - there is no standard elsewhere. I was extracting the Bayer data from early camera flash-dump experiments (which I don't entirely understand...) In those early dumps the .RAW was at offset 0x12000 and the corresponding Bayer data was at 0x120000 (if I remember correctly). For my camera (Wolf/Ritz Red 6410) the CMOS data is 1288 wide x 864 high. Thus, the .BYR files I'm dealing with are 1288x864 bytes long = 11135232 bytes (0x10FB00 in hex). However, I came across a .RAW file from one camera where the data is 1284 x 864 - this was one where the Foxz2 driver creates a "blue hue" image. The .BYR data from that image would be a bit smaller (1728 bytes smaller, to be specific). I read through the DNG spec yesterday at lunchtime - doesn't look too bad. It is a TIFF file with some additional tags and the ability to store uncompressed Bayer data. The additional tags let you clearly specify raw image things for the reader - like what value is pure white, what value is pure black, which border areas of the raw Bayer data are present just for making interpolation work right at the edges. Seems straightforward - and seems like we can get a lot of the data from the SMaL .RAW file header or from some experimentation. Ultimately I want to build this into the same program which is converting the .RAW image data. But, the simplest start would be an application that is coded with a bunch of assumptions (eg. image size = 1288x864, 2-pixel interpolation borders, etc.), reads a .BYR file to get the image data and writes out a valid .DNG file. This could be used with a .DNG reader (ex. Adobe PhotoShop) to make sure that the .DNG file is correctly formatted and contains all necessary tags. The second step would be to read a .BYR and the header from a .RAW file to set .DNG tag fields more dynamically from real data - this would give you IMG_0001.RAW + IMG_0001.BYR => IMG_0001.DNG. The final step would be to integrate these together so that it does IMG_0001.RAW => IMG_0001.DNG. Though, the intermediate step (RAW + BYR -> DNG) will be very useful for figuring stuff out. This would let you use the Bayer data dumped from camera flash (or dumped from TWAIN driver memory) combined with the .RAW header information to produce .DNG image files that can be loaded and displayed. Once my .RAW decode is done (or at least works for most images) then that code will produce the .BYR/Bayer data from the .RAW, but there's no reason the next step of image processing needs to wait for me since we already have the Bayer data today. - sailpix _/) 03-27-2005 12:49:01

RE:Decompression - 1 2 many 4 all (modified 0 times) Drmn4ea Profile Anyone volunteered on the *.DNG stuff yet? I've been busy lately playing on the hardware end of things; still poking at the CMOS imager to try and get an image out of it (figured out what *most* of the lines do; should be a lot easier now that I've been able to borrow a 'scope), and wrote an LCD panel interface (testing it with a different panel, but the data interface is pretty similar to the one on the PV2). I guess I'm sort of saturated for the near term (may look at the DNG conversion stuff if no one else steps forward), but I'd be glad to volunteer integrating everyone's code into a GUI download/process tool. Thinking it would make the most sense just to build the PV2 download/process into the existing SUCR code, so as to have one tool that does it all. What do you think? 03-30-2005 12:53:50

RE:Decompression - 1 2 many 4 all (modified 1 times) sailpix Profile No volunteers yet... oh well. No big problem - I'll dive into it myself soon. I've written TIFF files before in the past, so the learning curve is not that steep for me. OTOH, I'm gonna pause this line of hacking for several weeks in April - apparently I can't take these toys along on my honeymoon. So, if anyone else can get involved before then it will maintain the progress. I'm trying to get the .RAW conversion code to a releaseable state before we head off travelling. I've talked a bit off-line to ForkBoy. He's interested in integrating my stuff into PV2Tool also. I need to take a look and see how easy it would be for me to post my code to billw's new SourceForge project. I picked up a FlatFoto 2.0 Megapixel camera at RadioShack yesterday - current price is $49.99. There are also a bunch on eBay, but sometimes they get up into the $45 range there, so I just bought the one I saw locally. RadioShack apparently only offered that model for the 2004 Christmas season - now they're selling off what they have. I wonder if they'll keep the drivers off-line after they sell all the hardware? I don't see SMaL chipsets going into any new cameras these days... I assume the Ultra-Pocket 3 Kit is the basis for these one-time use camera and the Ultra-Pocket 4 Kit is probably the basis for the FlatFoto 2.0 megapixel camera. I haven't noticed /any/ cameras built on their 3.0 megapixel Ultra-Pocket 5 Kit. Perhaps they have shifted focus to their automotive cameras and aren't really pushing the still-image stuff. I noticed that the FlatFoto2 LCD is _live_ with data from the imager - I wonder if that would be possible with new firmware in the one-time use cameras or if there's a different path through the FlatFoto 2.0 ASIC? I'll open it up to take a peek and note hardware - someday... But, now I have a copy of the FlatFoto 2 driver CD to work with and a camera which will produce various image size .RAW files. - sailpix _/) 03-30-2005 14:31:56

RE:Decompression - 1 2 many 4 all (modified 0 times) bentfork Profile sailpix I should be able to help you out with the image decoding. I am in the middle of moving my work offices halfway across the city right now, and am currently short a win32 development machine... I do have a mac I can play with. Is your code portable? Have you tried playing with the GD library? ( http://www.boutell.com/gd/ ) If you look at the copyright statement on the twain drivers a lot of their code is being used by smal. It should help save a lot of the image reading/writing code. email $MYUSERID at gmail.com if you are interested. 03-30-2005 15:37:24

RE:Decompression - 1 2 many 4 all (modified 0 times) MicronEye Profile FYI: I ran across this info as the company made news by being acquired by ominvision. Their technology looks most applicable to scientific applications (microscopes etc.) yet they were acquired by a company known for large sales for cell phone cameras. My understanding is that with this optical insertion, wider aperature and greater depth of focus is traded for a defocused raw image and companion signal processing. http://www.cdm-optics.com/site/extended_dof.php There are lots of interesting things to explore including the comparison images: http://www.cdm-optics.com/site/gallery.php Reading a previous post of someone wishing "good luck" at decoding, it thought this was pertinant because one could do their best at bayer decoding etc. and still end up with a defocused image if this technology were incorporated. I don't have any reason to think this is used in the cvs cameras - just something to be aware of. 04-01-2005 15:30:56

RE:Decompression - 1 2 many 4 all (modified 0 times) mako Profile I'd like to help out, but 1: midterms are coming up, and 2: I don't know anything about image file formats, compression schemes, and the like. I'd definitely like to learn though. Are there any good books to start off with? 04-02-2005 04:00:49

Reply to Thread | Printer | All times are PST Powered by UltraBoard v1.62

I-Appliance BBS General - NEWS, Breaking NEWS - linux-hacker.net BBS on CD Questions - User Groups in Your Town - E-Bay, Yahoo Auction LINKS ONLY (MODERATED) - Jokes & Humor - usdtv box I-Opener Areas - I-Opener General Posts - I-Opener Technical Stuff - I-Opener Technical Info Reference (MODERATED) WebSurfer Areas - WebSurfer General Posts - WebSurfer Technical Stuff - WebSurfer Technical Info Reference (MODERATED) Other I-Appliances - Virgin Webplayer - WebPal - MailStation - 3Com Audrey - ThinkNIC / Oracle NIC - Gateway/AOL Connected Touch Pad - Philips/AOL-TV - ACER NT-150 STB - MSN Companion - Compaq IA - Emachines IA - IBM NetVista IA - Intel dot.station - MSNTV2 Network Computers - Fujitsu-Siemens Scovery Linux Net Computers - GallantWeb Server Consoles - Dreamcast - xbox hacking Web Pads - Epods One General Post - Panasonic CF-01 - Fujitsu Stylistic 1200 - Cybiko Thin Clients - Thin Clients DigitalVideoRecorders - DTV Recorders, Replay, TiVo, Etc... - Tivo Hacks Linux - Midori Linux General Board - ITX MotherBoards Single Board Computers - Earth Computers mARMalade Elite Member Area MISC Areas - The Swap Meet WE TAKE NO RESPONSIBILITY FOR ANY TRANSACTION HERE AND NO COMMERCIAL POST PERIOD !!! - Wireless Net - Cameras - Robotics - Routers/Gateways - Mattel JuiceBox