Converting Konica Picture Show images to JPEG images
Lad A. Jelen
Is there a way to convert Konica .kqp images to JPEG images directly
without doing an export through Windows? It shouldn't be too hard,
considering that the .kqp format is basically a JPEG file with a
unique header attached to it.
Tom Lane
Last I looked, Konica was deliberately making it difficult to do this
conversion without their software. kqp files seem to contain a large
(kilobyte-plus) BMP header followed by a reasonably standard JPEG
datastream. Except that the JPEG datastream is missing the DQT tables
--- essentially, the quality setting info. There is a small proprietary
marker that probably tells the Konica decoder which set of tables to
use. Simply stripping off the BMP header will *not* give you a file
that a standard JPEG decoder can use.
Making a kqp-to-jfif converter would be a pretty trivial programming
task, except for accumulating the info about marker content to DQT
table correspondence. Even that could probably be done by twiddling
the marker contents and seeing what Konica's decoder outputs when
asked to convert to JFIF. If anyone cares to tackle the project,
I'd be pleased to offer advice.
regards, tom lane
organizer, Independent JPEG Group
Edward Hamrick
In article <TGL.96Oc...@netcom17.netcom.com>,
Tom Lane <t...@netcom.com> wrote:
>
>table correspondence. Even that could probably be done by twiddling
>the marker contents and seeing what Konica's decoder outputs when
>asked to convert to JFIF. If anyone cares to tackle the project,
>I'd be pleased to offer advice.
I've attached what I think the Konica .KQP image format is. It looks
like it's just a file with some junk at the top, 1024 bytes of
palette data (R, G, B, and a wasted zero), and then a JFIF file
with the DQT and DHT markers omitted to make it harder to
reverse-engineer.
The .KQP format also has the old Pegasus error of setting the JPEG
version to 2.01 instead of 1.02. It looks like the whole .KQP mess
is due the Konica software not wanting to compute the optimal palette,
and instead storing the palette with the image. Since the IJG code
computes the palette nicely, the .KQP mess is probably due to Konica
trying to do what Seattle Filmworks is trying to do - make people use
their software or buy their software from them. Note that Pegasus
is trying to get people to buy their JPEG libraries by using .KQP
reading as a "feature", but it's just a gimmick due to their inside
knowledge of the .KQP format (and they won't document it either).
I'll add support for .KQP to VuePrint if at least 10 people ask
for it, but so far, nobody has asked for it. I did a similar thing
for adding support for the Casio QV-10/QV-100 .CAM format to VuePrint, which
was the same kind of kludged JFIF format. It turns out that I added the
.CAM file support to the IJG version 6.0 code by modifying the
jdatasrc.c routine to make the higher levels of the IJG code think
it was reading a standard JFIF file. A similar modification to this
same routine is all it would take to add .KQP support.
(It was actually a bit trickier to add the .CAM support, since
it also uses a goofy aspect ratio.)
Regards,
Ed Hamrick
http://www.hamrick.com/
Format of a Konica .KQP file:
KQP file header:
42 4D 00 00 00 00 00 00 00 00
Offset into file of JFIF data (4 bytes)
42 04 00 00 (I don't know if it's the same for all .KQP files)
Miscellaneous junk, including 1024 bytes of
pre-calculated palette data:
(misc data deleted)
SOI marker:
FF D8
APP0 marker: (version is 2.01 in .KQP file, 1.02 in .JPG file)
FF E0 00 10 4A 46 49 46 00 01 02 02 00 00 00 00
00 00
APP1 marker:
FF E1 00 0A 50 49 43 00 01 0E 0E 01
SOF0 marker:
FF C0 00 11 08 01 90 02 58 03 01 11 00 02 11 01
03 11 01
DQT marker: (implicit - not included in .KQP file)
FF DB 00 84 00 07 04 05 06 05 04 07 06 05 06 07
07 07 08 0A 11 0B 0A 09 09 0A 15 0F 10 0C 11 19
16 1A 1A 18 16 18 18 1C 1F 28 22 1C 1D 26 1E 18
18 23 2F 23 26 29 2A 2D 2D 2D 1B 21 31 34 31 2B
34 28 2C 2D 2B 01 07 07 07 0A 09 0A 14 0B 0B 14
2B 1C 18 1C 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B
2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B
2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B 2B
2B 2B 2B 2B 2B 2B
DHT marker: (implicit - not included in .KQP file)
FF C4 01 A2 00 00 01 05 01 01 01 01 01 01 00 00
00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A
0B 10 00 02 01 03 03 02 04 03 05 05 04 04 00 00
01 7D 01 02 03 00 04 11 05 12 21 31 41 06 13 51
61 07 22 71 14 32 81 91 A1 08 23 42 B1 C1 15 52
D1 F0 24 33 62 72 82 09 0A 16 17 18 19 1A 25 26
27 28 29 2A 34 35 36 37 38 39 3A 43 44 45 46 47
48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66 67
68 69 6A 73 74 75 76 77 78 79 7A 83 84 85 86 87
88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3 A4 A5
A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA C2 C3
C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8 D9 DA
E1 E2 E3 E4 E5 E6 E7 E8 E9 EA F1 F2 F3 F4 F5 F6
F7 F8 F9 FA 01 00 03 01 01 01 01 01 01 01 01 01
00 00 00 00 00 00 01 02 03 04 05 06 07 08 09 0A
0B 11 00 02 01 02 04 04 03 04 07 05 04 04 00 01
02 77 00 01 02 03 11 04 05 21 31 06 12 41 51 07
61 71 13 22 32 81 08 14 42 91 A1 B1 C1 09 23 33
52 F0 15 62 72 D1 0A 16 24 34 E1 25 F1 17 18 19
1A 26 27 28 29 2A 35 36 37 38 39 3A 43 44 45 46
47 48 49 4A 53 54 55 56 57 58 59 5A 63 64 65 66
67 68 69 6A 73 74 75 76 77 78 79 7A 82 83 84 85
86 87 88 89 8A 92 93 94 95 96 97 98 99 9A A2 A3
A4 A5 A6 A7 A8 A9 AA B2 B3 B4 B5 B6 B7 B8 B9 BA
C2 C3 C4 C5 C6 C7 C8 C9 CA D2 D3 D4 D5 D6 D7 D8
D9 DA E2 E3 E4 E5 E6 E7 E8 E9 EA F2 F3 F4 F5 F6
F7 F8 F9 FA
SOS marker:
FF DA (followed by image-dependant data)
EOI marker:
FF D9
Tom Lane
ham...@primenet.com (Edward Hamrick) writes:
> I've attached what I think the Konica .KQP image format is. It looks
> like it's just a file with some junk at the top, 1024 bytes of
> palette data (R, G, B, and a wasted zero), and then a JFIF file
> with the DQT and DHT markers omitted to make it harder to
> reverse-engineer.
Hmm. The examples I've seen *did* include DHT tables. Do you suppose
that Konica has been changing their format as time passes?
> The .KQP format also has the old Pegasus error of setting the JPEG
> version to 2.01 instead of 1.02.
Yes, I believe Jack Berlin has stated that Pegasus supplied Konica's
JPEG software. You'd think they'd fix this bug while updating their
software ... except, of course, actually being standard is the furthest
thing from their minds.
> It looks like the whole .KQP mess
> is due the Konica software not wanting to compute the optimal palette,
> and instead storing the palette with the image.
Well, you can argue the merits of a precomputed palette for JPEG files;
I've come down on the "waste of bytes" side, but there are reasonable
arguments on the other side. BUT: you could perfectly well put a
precomputed palette into an application-specific JPEG marker, which'd
be ignored by other decoders, thus preserving compatibility. There's
no need to create an incompatible format for that.
And the decision to omit DQT in favor of (what appears to be) a one-byte
quality indicator field is just plain brain-dead. If they ever want
to adopt an improved quality scaling procedure, they won't be able to
do it without breaking their old decoders.
I can't interpret the format as anything but a lame attempt to prevent
other applications from reading their files. (It's lame because it's
so ineffective ... a few cycles spent on encryption would be much
more effective ;-).)
> DQT marker: (implicit - not included in .KQP file)
BTW, I don't believe that all KQP files use the same quant tables;
I have examples with two different sets, and there may be more.
That APP1 marker probably carries an indicator of which table set to
use.
Edward Hamrick
>> I've attached what I think the Konica .KQP image format is. It looks
>> like it's just a file with some junk at the top, 1024 bytes of
>> palette data (R, G, B, and a wasted zero), and then a JFIF file
>> with the DQT and DHT markers omitted to make it harder to
>> reverse-engineer.
>
>that Konica has been changing their format as time passes?
There may be a flag indicating absence/presence of DHT, or the
DHT may be a default value if there isn't one in the file.
>> It looks like the whole .KQP mess
>> is due the Konica software not wanting to compute the optimal palette,
>> and instead storing the palette with the image.
>
>Well, you can argue the merits of a precomputed palette for JPEG files;
>I've come down on the "waste of bytes" side, but there are reasonable
>arguments on the other side. BUT: you could perfectly well put a
>precomputed palette into an application-specific JPEG marker, which'd
>be ignored by other decoders, thus preserving compatibility. There's
>no need to create an incompatible format for that.
I agree - the incompatible format was a real waste of time.
>And the decision to omit DQT in favor of (what appears to be) a one-byte
>quality indicator field is just plain brain-dead. If they ever want
>to adopt an improved quality scaling procedure, they won't be able to
>do it without breaking their old decoders.
Unless they were far-sighted enough to have a value that says
"use the DQT that's in the file itself".
>I can't interpret the format as anything but a lame attempt to prevent
>other applications from reading their files. (It's lame because it's
>so ineffective ... a few cycles spent on encryption would be much
>more effective ;-).)
I agree - it's completely lame, and a simple encryption scheme would
have been a lot more effective.
By the way, have you ever figured out the Seattle Filmworks .SFW
format? It looks like it may be a JFIF format with the markers
changed to different values.
>> DQT marker: (implicit - not included in .KQP file)
>
>BTW, I don't believe that all KQP files use the same quant tables;
>I have examples with two different sets, and there may be more.
>That APP1 marker probably carries an indicator of which table set to
>use.
Hmm, you're probably right. I still haven't gotten a single
e-mail requesting that I add .kqp support to VuePrint, so I'm not
going to worry about it.
Edward Hamrick
In article <55d2h5$4...@nnrp1.news.primenet.com>,
Edward Hamrick <ham...@primenet.com> wrote:
>In article <TGL.96Oc...@netcom17.netcom.com>,
>Tom Lane <t...@netcom.com> wrote:
>
>By the way, have you ever figured out the Seattle Filmworks .SFW
>format? It looks like it may be a JFIF format with the markers
>changed to different values.
Answering my own question <smile>, I dug up a Seattle Filmworks
.SFW file, and it's just a JPEG file with a header at the front and
the marker codes changed. For instance, the marker codes they
changed:
SOI D8 -> C8
APP0 E0 -> D0
DQT DB -> CB
SOF0 C0 -> A0
SOS DA -> CA
EOI D9 -> C9
They also put different fields in the APP0 marker:
53 46 57 39 34 00 00 00 00 01 00 01 00 00
S F W 9 4
The standard JFIF APP0 marker is:
4A 46 49 46 00 01 01 00 00 01 00 01 00 00
J F I F
The whole .SFW and .KQP fiasco is a clear attempt
by the film scanning industry to use JPEG technology,
but to slightly change the format to lock people into
their software. I recommend avoiding both Seattle
Filmworks and Konica until they stop locking people into
their inferior viewer software by using proprietary
file formats.
It's amusing to see the nonsense that Seattle Filmworks
and Konica put on their web sites about the super-duper
technology they use in compressing the images, when in
actuality they're just sending normal JPEG files to
people, with some small changes to make it impossible
for people to use regular JPEG viewers with these images.
Andy
Tom Lane wrote:
>
> af...@cleveland.Freenet.Edu (Lad A. Jelen) writes:
> > Is there a way to convert Konica .kqp images to JPEG images directly
> > without doing an export through Windows? It shouldn't be too hard,
> > considering that the .kqp format is basically a JPEG file with a
> > unique header attached to it.
>
> Last I looked, Konica was deliberately making it difficult to do this
> conversion without their software. kqp files seem to contain a large
> (kilobyte-plus) BMP header followed by a reasonably standard JPEG
> datastream. Except that the JPEG datastream is missing the DQT tables
> --- essentially, the quality setting info. There is a small proprietary
> marker that probably tells the Konica decoder which set of tables to
> use. Simply stripping off the BMP header will *not* give you a file
> that a standard JPEG decoder can use.
>
> Making a kqp-to-jfif converter would be a pretty trivial programming
> task, except for accumulating the info about marker content to DQT
> the marker contents and seeing what Konica's decoder outputs when
> asked to convert to JFIF. If anyone cares to tackle the project,
> I'd be pleased to offer advice.
>
> organizer, Independent JPEG Group
Are you so sure the resulting decompressed image will be a color JPEG
image? Most of the cameras I worked with simply stored the raw
unprocessed, BW, color masked image in their "Proprietary" format for
later processing (Dycam, Chinon, Kodak). What you might get if you
decode the image is a monochrome image full of stripes or spots.
Andy
Tom Lane
ac...@mailmasher.com (acorn) writes:
> Please, Tom, spare us the lecture and answer the question for us ..
> Please!! IS there a way to convert them to .jpg or not??????
If I knew of a program to do it, I would've said so. I thought it was
pretty clear from my previous post that I was fishing for a volunteer
to make such a program...
Anonymous
If you can display a Konica image on-screen,
why not use an image-capture utility (Hijack, etc.) to resave the image?
My 2-cents worth...
Edward Hamrick
In article <327A5D...@boi.hp.com>, Andy <an...@boi.hp.com> wrote:
>
>Are you so sure the resulting decompressed image will be a color JPEG
>image? Most of the cameras I worked with simply stored the raw
>unprocessed, BW, color masked image in their "Proprietary" format for
>later processing (Dycam, Chinon, Kodak). What you might get if you
>decode the image is a monochrome image full of stripes or spots.
I'm positive that the .KQP and .SFW files are transformable to
JPEG/JFIF files - I've actually done it, editing the headers by
hand and using a JPEG viewer.
Both file types are definitely standard JPEG files with non-standard
headers added to make it impossible for normal JPEG readers to read
these images.
You're right that the Kodak .KDC files are _not_ masked JPEG
files - they are TIFF files with proprietary tag types. Interestingly,
if you view a .KDC file with a normal TIFF reader, you see the 96x64
thumbnail image.
Regards,
Ed Hamrick
jim.v...@gmail.com
> Is there a way to convert Konica .kqp images to JPEG images directly
> without doing an export through Windows? It shouldn't be too hard,
> considering that the .kqp format is basically a JPEG file with a
> unique header attached to it.
Savageduck
> On Thursday, October 31, 1996 3:00:00 AM UTC-5, Lad A. Jelen wrote:
>> Is there a way to convert Konica .kqp images to JPEG images directly
>> without doing an export through Windows? It shouldn't be too hard,
>> considering that the .kqp format is basically a JPEG file with a
>> unique header attached to it.
>
Why are we getting a bunch of responses to antique posts?
1996! Who cares other than some random spammer?
--
Regards,
Savageduck
nospam
> On 2014-05-30 18:42:23 +0000, jim.v...@gmail.com said:
> > On Thursday, October 31, 1996 3:00:00 AM UTC-5, Lad A. Jelen wrote:
> >> Is there a way to convert Konica .kqp images to JPEG images directly
> >> without doing an export through Windows? It shouldn't be too hard,
> >> considering that the .kqp format is basically a JPEG file with a
> >> unique header attached to it.
> >
> > For anyone who looks at this question recently, tr......
>
> Why are we getting a bunch of responses to antique posts?
> 1996! Who cares other than some random spammer?
zombiehac...@gmail.com
tincu...@gmail.com
> Is there a way to convert Konica .kqp images to JPEG images directly
> without doing an export through Windows? It shouldn't be too hard,
> considering that the .kqp format is basically a JPEG file with a
> unique header attached to it.
Alan Browne
> On Thursday, October 31, 1996 at 4:00:00 AM UTC-4, Lad A. Jelen wrote:
>
> I see this question you have posed was 9 years
--
"But I am somehow extraordinarily lucky, for a guy with shitty luck."
..Harrison Ford, Rolling Stone - 2015-12-02
m.carpe...@gmail.com
Regards,
Marilyn
nospam
<http://www.xnview.com/en/xnconvert/>
theb...@gmail.com
> Is there a way to convert Konica .kqp images to JPEG images directly
> without doing an export through Windows? It shouldn't be too hard,
> considering that the .kqp format is basically a JPEG file with a
> unique header attached to it.