OrigamiSat-2 jpg creating on LINUX
I asked ChatGPT why it's not possible to convert this HEX data of the second image from the bottom to a JPEG image. Then, the following response was received. By performing the steps in the latter half on this my article, 100% JPEG images could be successfully generated. ---------------------------------------------------------------- This HEX data has a structure that is very characteristic of a JPEG file. In fact, it contains: * Start marker: "FFD8" * JFIF header: "FFE0...4A464946" * DQT: "FFDB" * SOF0: "FFC0" * Huffman Table: "FFC4" * Start of Scan: "FFDA" * End marker: "FFD9" So this is not “completely corrupted data.” However, there are some problematic areas. ### Problem 1: Abnormal Huffman Table This section: "FFC4001F00000105010101010117BB01..." In a JPEG "FFC4" (Huffman Table), the length-definition portion must contain properly structured values. However: "...01010117BB01..." The "17BB" part is extremely unnatural. Normally, this area would look something like: "0101010101010101" with only small values. The sudden appearance of "BB" is typical of: * a missing byte * bit misalignment * HEX contamination * corrupted copying ### Problem 2: The Quantization Table Also Looks Suspicious This section: "FFDB00430006040506050406060506070706080A100A..." looks normal at first glance, but the latter part differs slightly from standard JPEG tables. This suggests that: * part of the data was overwritten * corruption occurred during transmission * data may have been lost during log storage ### Problem 3: Unnatural Values in the Middle This section: "...E6E70E05E8E9EA..." is highly unusual for a JPEG Huffman definition. Normally it would continue like: "E7E8E9EA" in sequence. This strongly suggests that "0E05" was accidentally inserted into the stream. ### Conclusion This JPEG: * contains a valid header * mostly preserves the JPEG structure However, because the Huffman Table is corrupted, standard JPEG decoders will likely report errors such as: * “Invalid JPEG” * “Corrupted file” * “SOS marker error” * “Huffman table error” ### What Most Likely Happened There is a very high probability that your data was extracted from something like: * a serial log * communication log * UART dump * memory dump * partially copied data and that a few bytes were either lost or inserted. In particular: * "17BB" * "0E05" * "69DD" are especially suspicious. There is still a possibility that the file can be repaired. This JPEG appears to have: * a mostly intact structure * valid size information * valid SOF/SOS markers Therefore, recovery may be possible by: * replacing the Huffman Table with a standard Huffman Table * removing corrupted bytes Because this is a Baseline DCT JPEG, repair using a standard Huffman Table is especially effective. In conclusion, the image data itself (everything after SOS) is very likely still intact, while only the DHT section appears corrupted. Therefore, the most reliable way to recover the image is to completely replace the entire DHT with a standard Huffman Table. ---------------------------------------------------------------- Manually explaining all eight of the images above would be very time-consuming, so I've semi-automated the process using a programming language based on Ruby. The number of iterations (38c) in the rb file used to generate test1.hex should be adjusted to match the number of rows in the CSV file downloaded from SatNOGS. Note that after generating test2.hex, the last line containing FFD9 is generally short, so you will need to manually edit that part. The final file, test3.hex, has a JPEG structure with a single row of "FFD8...FFD9". https://www.ne.jp/asahi/hamradio/je9pel/cas5atst.htm Sample satnogs.csv: total_lines 908(d)=38c(h) Image No.44(h) on 8 May 2026 by JH4XSY test0.sh ... Shell script using Ruby to output ext044.rb test1.hex ... Extract the right side including the frame number of each row. test2.hex ... Extract the data body from each row, excluding the frame number. Edit last line in it ending with FFD9 manually. test3.hex ... Concatenate each line in test2.hex into one single line. The result starts with FFD8 and ends with FFD9. Edit it according to ChatGPT when JPEG image is not generated. [ext044.rb] > for i in 0..0x38c > printf("grep 020003%04X satnogs.csv | head -1 | cut -c 77- >> test1.hex\n", i) > end [on Terminal] $ ruby ext044.rb > test0.sh $ sh test0.sh $ cut -c 5-384 test1.hex > test2.hex > Edit last line in test2.hex ending with FFD9. $ tr -d '\n' < test2.hex > test3.hex > Edit test3.hex according to ChatGPT. $ cat test3.hex | xxd -r -p > test3.jpg ---------------------------------------------------------------- In summary, by modifying the HEX data as suggested by ChatGPT, I,JE9PEL was able to convert only a small portion of the original image (top left) into a JPEG image. (Still in the trial-and-error phase, 10 May 2026) 60509or0.csv 60509or1.hex 60509or2.hex 60509or3.hex $ cat 60509or3.hex | xxd -r -p > 60509or3.jpg ---------------------------------------------------------------- 2026-05-22 06:05 UTC in SatNOGS, Even for the same sequence number, there were many different data sets, so I displayed four rows of data for each sequence number using Ruby, and then manually selected only one reliable row as the data for that sequence number. At the end of the process, I used Google Gemini to modify the Huffman Table in JPEG format. I was able to obtain the following image after working on it all day since this morning, (Cf.JA3TDW) [ext044.rb] > for i in 0..0x50e > printf("grep 020005%04X 60523ori.csv | head -4 | cut -c 77- >> 60523or1.hex\n", i) > end [on Terminal] $ ruby ext044.rb > 60523or0.sh $ sh 60523or0.sh > Extract only one row reliable sequence number data. $ cut -c 5-384 60523or1.hex > 60523or2.hex > Edit last line in 60523or2.hex ending with FFD9. $ tr -d '\n' < 60523or2.hex > 60523or3.hex > Edit 60523or3.hex according to ChatGPT or Gemini. $ cat 60523or3.hex | xxd -r -p > 60523or3.jpg By using "cut -c 5-384" to remove the last two bytes (CRC Check) from the end of each line of the HEX data, all the error messages that had been occurring disappeared, and I was able to obtain 100% JPEG images.
22 May 2026 | 23 May 2026 | 27 May 2026 |
