Konica PictureShow graphics format
Dick Streefland
When you get your photos developed at Thrifty Payless, you can get your
pictures put on a floppy disk. This service is called Konica PictureShow
(tm). I just tried this out and I got two disc back for a 36 exposures
film. Included on the floppy is software to view your pictures on DOS or
MS-Windows. I like to manipulate these pictures on a Unix machine using
'xv', but the graphics format doesn't seem to be standard. When I load
it, xv complains about a bogus BMP file. The Windows version has an
export function, but I don't use MS-Windows. The beginning of the file
looks like:
0: 42 4d 00 00 00 00 00 00 00 00 42 04 00 00 44 00 BM........B...D.
10: 00 00 58 02 00 00 70 fe ff ff 01 00 18 00 4a 50 ..X...p.......JP
20: 45 47 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 EG..............
30: 00 00 ec 00 00 00 2c 00 00 00 18 00 00 00 00 00 ......,.........
Does anybode know what graphics format this is, and if there are
convertors for it?
Thanks,
--
Dick Streefland //// Tasking Software BV
di...@tasking.nl (@ @) The Netherlands
------------------------oOO--(_)--OOo------------------------
Tom Lane
di...@tasking.nl (Dick Streefland) writes:
> The beginning of the file looks like:
> 0: 42 4d 00 00 00 00 00 00 00 00 42 04 00 00 44 00 BM........B...D.
> 10: 00 00 58 02 00 00 70 fe ff ff 01 00 18 00 4a 50 ..X...p.......JP
> 20: 45 47 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 EG..............
> 30: 00 00 ec 00 00 00 2c 00 00 00 18 00 00 00 00 00 ......,.........
> Does anybode know what graphics format this is, and if there are
> convertors for it?
Hmm, characters 1e-21 are a bit suggestive, wouldn't you say?
My guess is that this file follows Microsoft's stillborn "JPEG-in-BMP"
proposal, which up to just now I would've said no one, including
Microsoft, ever implemented.
I don't have the Microsoft document at hand, but I think it was another
variant on the JPEG-datastream-inside-proprietary-header theme. Look
to see if the sequence ff d8 ff occurs further along in the file;
if so, delete everything in front of that and see if it doesn't read
as a JPEG file.
If that doesn't work, let me know and I'll excavate for the MS document.
regards, tom lane
organizer, Independent JPEG Group
Dick Streefland
I think you guesses right, there is indeed an ff d8 ff sequence in the file:
0: 42 4d 00 00 00 00 00 00 00 00 42 04 00 00 44 00 BM........B...D.
10: 00 00 58 02 00 00 70 fe ff ff 01 00 18 00 4a 50 ..X...p.......JP
20: 45 47 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 EG..............
30: 00 00 ec 00 00 00 2c 00 00 00 18 00 00 00 00 00 ......,.........
40: 00 00 02 00 00 00 08 00 00 00 01 00 00 00 01 00 ................
...
430: 34 00 0c 30 44 00 90 74 18 00 08 48 1c 00 00 18 4..0D..t...H....
440: 10 00 ff d8 ff e0 00 10 4a 46 49 46 00 02 01 02 ........JFIF....
450: 00 00 00 00 00 00 ff e1 00 0a 50 49 43 00 01 14 ..........PIC...
460: 19 05 ff c0 00 11 08 01 90 02 58 03 01 11 00 02 ..........X.....
I tried loading the file starting at 0x442 in xv, but now I get the error
message: "Unsupported JFIF revision number 2.01". Do you have another
suggestion?
Tom Lane
di...@sj-coop.net (Dick Streefland) writes:
> Tom Lane (t...@netcom.com) wrote:
> | I don't have the Microsoft document at hand, but I think it was another
> | variant on the JPEG-datastream-inside-proprietary-header theme. Look
> | to see if the sequence ff d8 ff occurs further along in the file;
> | if so, delete everything in front of that and see if it doesn't read
> | as a JPEG file.
> I think you guesses right, there is indeed an ff d8 ff sequence in the file:
> 0: 42 4d 00 00 00 00 00 00 00 00 42 04 00 00 44 00 BM........B...D.
> 10: 00 00 58 02 00 00 70 fe ff ff 01 00 18 00 4a 50 ..X...p.......JP
> 20: 45 47 00 00 00 00 00 00 00 00 00 00 00 00 fc 00 EG..............
> 30: 00 00 ec 00 00 00 2c 00 00 00 18 00 00 00 00 00 ......,.........
> 40: 00 00 02 00 00 00 08 00 00 00 01 00 00 00 01 00 ................
> ...
> 430: 34 00 0c 30 44 00 90 74 18 00 08 48 1c 00 00 18 4..0D..t...H....
> 440: 10 00 ff d8 ff e0 00 10 4a 46 49 46 00 02 01 02 ........JFIF....
> 450: 00 00 00 00 00 00 ff e1 00 0a 50 49 43 00 01 14 ..........PIC...
> 460: 19 05 ff c0 00 11 08 01 90 02 58 03 01 11 00 02 ..........X.....
> I tried loading the file starting at 0x442 in xv, but now I get the error
> message: "Unsupported JFIF revision number 2.01". Do you have another
> suggestion?
(Rolls eyes...) Sorry, I thought their cluelessness would be bounded,
but evidently it's infinite. The JPEG FAQ explains:
: At least one release of Hijaak Pro writes JFIF files that claim to be
: revision 2.01. There is no such spec; the latest JFIF revision is 1.02.
: It looks like HiJaak got the high and low bytes backwards. Unfortunately,
: most JFIF readers will give up on encountering these files, because the JFIF
: spec defines a major version number change to mean an incompatible format
: change. If there ever *were* a version 2.01, it would be so numbered
: because current software could not read it and should not try. (One wonders
: if Hijaak has ever heard of cross-testing with other people's software.)
: If you run into one of these misnumbered files, you can fix it with a
: binary-file editor, by changing the twelfth byte of the file from 2 to 1.
It would seem that Konica licensed Hijaak's broken software and then
used it to implement the universally-unsupported JPEG-in-BMP format.
JPEG-in-BMP has no use for the JFIF marker, which is what contains
the JFIF version number, but they didn't bother to take it out.
Oh well, it's still better than the first release of the Konica
software, which produced alleged-JPEG files that were *completely*
unreadable. As best I could tell, they were packing the Huffman
codes into bytes in the wrong order, low-bit-to-high rather than
high-bit-to-low.
Bottom line: if you strip off the data before ff d8 (first 442-hex
bytes in this example, probably but not certainly the same in all)
and then set byte 12 of the remaining data to 1, you'll probably
be OK. (Or recompile xv with a more recent release of the IJG
software --- v6 and later treat unknown major JFIF version number
as a warning, rather than the error it ought to be, solely and
only to work around Hijaak's inability to read the spec.)
Sorry, I'm in a bad mood. This does sound like a new low in
programmer competence and/or disinterest in compatibility,
however. Maybe they *want* you to have to use their software
to decode their files.
Dick Streefland
I changed the version number and now I get yet another error message:
Quantization table 0x00 was not defined
Time to give up?
| Sorry, I'm in a bad mood. This does sound like a new low in
| programmer competence and/or disinterest in compatibility,
| however. Maybe they *want* you to have to use their software
| to decode their files.
... which is too bad. Besides being forced to use MS-Windows, you
cannot do it in batch mode, so you have to sit down and click a few
hundred times to convert one film.
Thanks for your help anyway,
Tom Lane
di...@sj-coop.net (Dick Streefland) writes:
> I changed the version number and now I get yet another error message:
> Quantization table 0x00 was not defined
> Time to give up?
A followup for anyone else who was following this discussion ---
Dick and I investigated this problem some more off-line. Also,
I heard from Jack Berlin of Pegasus Imaging Corporation, who
claim to be the suppliers of Konica's software. Here's the
bottom line:
1. The current Konica image format (.KGP) consists of a JPEG
datastream preceded by a BMP-style file header and a BMP-style
palette. Konica's software uses the palette as a color quantization
target when displaying the image on a 256-color display.
2. The JPEG datastream contains an erroneous JFIF marker: it claims
to be version 2.01, which corresponds to no extant version of the
JFIF standard. Since the BMP header makes the file non-JFIF, the
JFIF marker is a waste of bytes anyway.
3. The JPEG datastream also omits the quantization tables (DQT
markers), which makes the file undecodable by a standard JPEG decoder
even if one deletes the BMP data and bogus JFIF marker.
4. The JPEG datastream does include an "APP1" application-defined
marker, which Pegasus says includes a field that tells which set of
quantization tables was used. They haven't seen fit to publish the
details, however, and in any case no standard decoder will do anything
but ignore the Pegasus APP1 marker.
IMHO, points 3 and 4 represent a deliberate attempt to sabotage
compatibility and ensure that these files can't be decoded with
anything except Konica/Pegasus software. Omitting the tables
saves a grand total of about 128 bytes --- only half of what was
wasted by their decision to store the color palette as 4 bytes/pixel
rather than 3 --- so saving space was certainly not the motivation.
What goes around comes around, however. By doing things this way,
Konica/Pegasus have ensured that they won't be able to use any
improved quantization table values without breaking compatibility
with their existing software (because their decoder only understands
a very limited subset of the possible quantization tables). I think
they'll live to regret this choice.
In the meantime, it *is* possible to convert the current crop of
Konica images to standard JFIF. You have to delete the first
thousand-and-some bytes of the BMP-like format and insert 150-odd
bytes of replacement header containing the proper quantization tables.
Dick Streefland has the details if anyone cares.
Dick Streefland
| In the meantime, it *is* possible to convert the current crop of
| Konica images to standard JFIF. You have to delete the first
| thousand-and-some bytes of the BMP-like format and insert 150-odd
| bytes of replacement header containing the proper quantization tables.
| Dick Streefland has the details if anyone cares.
You have to replace the first 1141 bytes of the .kqp file with a new
header of 185 bytes, taken from a .jpg file generated by the Konica
software. It seems that all generated .jpg files have identical
headers. I wrote a small (bash) shell script to do this.
--
Dick Streefland //// Tasking Software BV
di...@tasking.nl (@ @) The Netherlands
------------------------oOO--(_)--OOo------------------------
#!/bin/bash
tmp=/tmp/header$$
trap "rm -f $tmp" 0 2 3 15
(
echo "begin 644 $tmp"
cat <<'EOF'
M_]C_X``02D9)1@`!`@(```````#_X0`*4$E#``$4&0'_P``1"`&0`E@#`1$`
M`A$!`Q$!_]L`A``*!@<(!P8*"`@("PH*"P\9$`\-#0\>%1<2&20?)B4C'R,B
M*"TY,"@J-BLB(S)$,C8[/4!!0"8P1DM&/DLY/T`]`0T.#A(0$B04%"1-,RLS
M34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-34U-
%34U-34U-
`
end
end
EOF
) |
uudecode
for i
do
echo $i
case "$i" in
*.kqp)
jpg=${i%.kqp}.jpg
cat $tmp > $jpg
tail +1142c $i >> $jpg
;;
*)
echo "What should I do with \"$i\"?"
esac
done
Bob Johnson
t...@netcom.com (Tom Lane) writes:
>di...@sj-coop.net (Dick Streefland) writes:
>> I changed the version number and now I get yet another error message:
>> Quantization table 0x00 was not defined
>> Time to give up?
>A followup for anyone else who was following this discussion ---
>Dick and I investigated this problem some more off-line. Also,
>I heard from Jack Berlin of Pegasus Imaging Corporation, who
>claim to be the suppliers of Konica's software. Here's the
>bottom line:
[Konica format stuff omitted]
Thanks Tom for a very thorough and detailed review of the konica image format.
This should pave the way for someone to write a conversion routine to convert
".kpg" file to jpeg's soon. I agree that Konica will probably regret
the format they have chosen.
--Bob
===========================================================
Bob Johnson
Computer Programmer/Specialist
Biology Services Facility
University of Tennessee ///////// //////// //////////
123 Austin Peay Bldg. /// /// /// ///
Knoxville Tn 37996 ///////// /// ///////
423 974-4219 /// /// /// ///
bo...@utk.edu /////////// //////// ///
"Networking and Imaging for the Life Sciences"
===========================================================
`