- #Keiths ipod photo reader full
- #Keiths ipod photo reader code
- #Keiths ipod photo reader tv
- #Keiths ipod photo reader mac
Int xTimes2, xMinus1Times2, yOver2, yMinus1Over2 Int imagePixels = gImageWidth * gImageHeight Void DrawInterlacedYUV422SharedChrominanceImageIntoGWorld(unsigned char* buffer, GWorldWrapper* gww) Takes a buffer of bytes corresponding to a single image (so the buffer is exactly 691200 long) Int gImageWidth = 720, gImageHeight = 480
#Keiths ipod photo reader code
Note that my code produces final rgb values in the range, not or. You will have to pick around some of the Mac-graphics-specific details, but the general math is the same. If anyone has any idea what to do, I would appreciate it. I tried both of the following, and they produce freakish colors: I have tried some fairly standard conversions, such as YUV and YIQ, and so far the colors are all wrong. The problem is, the CLCL bytes have to be converted from their original values before they can be further converted into brightess, red, green, and blue for the final color.and I can't figure out what the conversion is. The other is that the first pixel gets the two chrominances present in the 4 bytes and the second pixel gets an average relative to the next 4 byte word. One is that both pixels use the same chrominance (they will have the same hue, or color, but their luminance is independent). There are two alternatives for chrominance. The luminance for the left pixel comes from the second byte, the luminance for the right pixel comes from the fourth byte. Each pair of pixels is stored in 4 bytes, and encoded CLCL, meaning a chrominance byte, a luminance byte, a chrominance byte, and another luminance byte.
#Keiths ipod photo reader full
Okay, I'm pretty sure the YUV is YUV 4:2:2, such that each pixel requires two adjacent pixels for its full information. I am soooooo close, but I am kind of out of ideas right now.ĭoes anyone have any idea what might be going on in the chrominance channels that I'm missing? In addition to YUV, I have tried YIQ, and as stated, I tried switching Q and I. I tried the obvious approach of the first four bits as U and the second as V, and I even tried switching it so V is first and then U, since Y was switch with UV in the first place. The colors just don't come out right at all. That left me with simply converting the first byte to UV, doing a simply YUV->RGB conversion, and I should be done. ithmb file, not bad for a few hours worth of work. I can now successfully open and produce perfect grayscale images from the. After some experimentation I discovered that the Y channel is actually in the second of each pair of bytes.which seems very odd to me, but nevertheless, that seems to be the case. This didn't work very well, much to my disappointment. I tried taking the first byte of each pair and interpreting it as luminance while discarding the chrominance. I finally figured out that that color encoding must not be RGB, it must be some luminance/chrominance separation, like YUV. Voila! Magnifier inspection suggests I have got this part right. So I interlaced the file, assuming even rows were in the first half of the file and odd rows were in the second half of the file. It became immediately obvious that this must be what is going on in the file format.
#Keiths ipod photo reader tv
It was clear that the spacial information was vertically doubled because the top half and the bottom half look like squashed versions of the us the colors were a complete disaster.Īfter much gnashing of teeth it dawned on me that this format is intended for TV output, which is interlaced.
#Keiths ipod photo reader mac
I copied off one image's worth of data into a separate file (691200 bytes) and started writing a Mac app to open and interpret the data.Īt first I tried a straight-forward 16-bit color mapping, packed as ARRRRRGGGGGBBBBB, where the A is an unused bit (designated A since that bit is used as a 1-bit alpha map in some cases). However, it clearly uses two bytes per pixels since that's how the math works out. I divided the total number of pixels (345600) into the number of photos in my library and got a perfect integer, suggesting the resolution is correct, it really does store 720x480. I determined from another thread that this stores 720x480 res images. I am working the largest resolution files, such as F1019_1.ithmb. Here's what I figured out this afternoon: If anyone is interested in helping me finish this off, I would like to write a simple Mac app that let's users view/parse/split/save/etc. ithmb file format yet? I am very very close. Please choose the appropriate forum for this topic.
0 kommentar(er)
