![]() |
News from da outaworlds |
mail files register groups login |
Message-ID: |
Pages:12345 |
Stefan Claas wrote:
> Rich wrote:
> > Stefan Claas <pollux@tilde.club> wrote:
> > > Rich wrote:
> > >
> > > > If instead you mean some kind of "special, PNG aware, encryptor that
> > > > only encrypted the bitmap data of a PNG", but left the file as
> > > > otherwise a proper PNG image structure, then that is slightly tricky
> > > > (and an algorithm that is only useful for PNG's alone).
> > >
> > > Yes, this is what I mean.
> >
> > Which brings up the question of: why?
> >
> > Why go to the trouble to create an encryptor that is specalized for
> > just encrypting the internal bitmap data within a PNG, leaving the rest
> > as a PNG file, when a generic "byte stream" encryptor will encrypt the
> > entire PNG with no extra effort?
>
> To make more content as allowed postable on social media, like X.
I.e, first you put data with file2png in a .png and then encrypt it
to finally post it. I can do this now with my xorpic program, but
I thought a solution with AES-GCM or XChaCha20+ploy1305 is better.
--
Regards
Stefan
Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>> > Rich wrote:
>> >
>> > > If instead you mean some kind of "special, PNG aware, encryptor that
>> > > only encrypted the bitmap data of a PNG", but left the file as
>> > > otherwise a proper PNG image structure, then that is slightly tricky
>> > > (and an algorithm that is only useful for PNG's alone).
>> >
>> > Yes, this is what I mean.
>>
>> Which brings up the question of: why?
>>
>> Why go to the trouble to create an encryptor that is specalized for
>> just encrypting the internal bitmap data within a PNG, leaving the rest
>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>> entire PNG with no extra effort?
>
> To make more content as allowed postable on social media, like X.
Ah, because the intermediate pipe is not transparent, and essentially
does the equivalent of 'file post.png' and disallows posting of
"post.png" files that do not return as "post.png: PNG image data, ...".
In which case, you would 'simplify' your 'image encryptor' if it
instead encrypted NetPBM [1] images, and relied upon the NetPBM tools
to convert the result to a PNG (or a GIF, or a 'whatever'). A NetPBM
image is a very short ASCII text header, followed by the raw binary
bitmap data (there is even an older ASCII bitmap data format for NetPBM
if you wanted to use that).
Then, you need:
1) a generic binary encryptor/decryptor
2) a very small utility to wrap/unwrap a NetPBM header onto the binary
data (you would take care of padding to/from a "rectangle" the
binary data here)
3) the NetPBM tools to convert to/from other image formats for actual
posting
I.e., here's a very small (10x10) PNG (created with GIMP, I used
exiftool to remove the 'created with GIMP' comment):
$ ls -l sc.png
-rw-r--r-- 1 110 Jan 5 11:20 sc.png
Here's the xxd encoded version:
$ xxd sc.png
00000000: 8950 4e47 0d0a 1a0a 0000 000d 4948 4452 .PNG........IHDR
00000010: 0000 000a 0000 000a 0802 0000 0002 5058 ..............PX
00000020: ea00 0000 0970 4859 7300 002e 2300 002e .....pHYs...#...
00000030: 2301 78a5 3f76 0000 0007 7449 4d45 07e9 #.x.?v....tIME..
00000040: 0105 1013 3242 3f8a 0a00 0000 0d49 4441 ....2B?......IDA
00000050: 5418 d363 6018 05a4 0300 0136 0001 1ad5 T..c`......6....
00000060: 8d17 0000 0000 4945 4e44 ae42 6082 ......IEND.B`.
Convert it to pnm:
$ pngtopam sc.png > sc.ppm
Here is what 'file' reports:
$ file sc.ppm
sc.ppm: Netpbm image data, size = 10 x 10, rawbits, pixmap
And the file is this ASCII header:
P6
10 10
255
followed by 298 ASCII null bytes:
$ xxd sc.ppm
00000000: 5036 0a31 3020 3130 0a32 3535 0a00 0000 P6.10 10.255....
00000010: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000020: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000030: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000040: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000050: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000060: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000070: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000080: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000090: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000a0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000b0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000c0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
000000f0: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000100: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000110: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000120: 0000 0000 0000 0000 0000 0000 0000 0000 ................
00000130: 0000 0000 0000 0000 00 .........
It is trivial to "replace" the binary part of the ppm file above with
an encrypted version thereof. Then the 'pamtopng' tool from NetPBM can
be used to convert the 'replaced' image back into a PNG (or GIF or TIFF
or one of numerous other formats, using other pamto or pnmto
converters).
[1] https://netpbm.sourceforge.net/
Note, I've used the Unix CLI tools above for ease of demonstration
purposes. NetPBM is also a library, so you very well may have a go
module for NetPBM available, where you can perform these transforms
from within go by calling the netpbm library rather than needing the
CLI toolset installed.
Stefan Claas <pollux@tilde.club> wrote:
> Stefan Claas wrote:
>> Rich wrote:
>> > Stefan Claas <pollux@tilde.club> wrote:
>> > > Rich wrote:
>> > >
>> > > > If instead you mean some kind of "special, PNG aware,
>> > > > encryptor that only encrypted the bitmap data of a PNG", but
>> > > > left the file as otherwise a proper PNG image structure, then
>> > > > that is slightly tricky (and an algorithm that is only useful
>> > > > for PNG's alone).
>> > >
>> > > Yes, this is what I mean.
>> >
>> > Which brings up the question of: why?
>> >
>> > Why go to the trouble to create an encryptor that is specalized
>> > for just encrypting the internal bitmap data within a PNG, leaving
>> > the rest as a PNG file, when a generic "byte stream" encryptor
>> > will encrypt the entire PNG with no extra effort?
>>
>> To make more content as allowed postable on social media, like X.
>
> I.e, first you put data with file2png in a .png and then encrypt it
> to finally post it. I can do this now with my xorpic program, but I
> thought a solution with AES-GCM or XChaCha20+ploy1305 is better.
The "path" I outlined in my previous post, where you utilize the netpbm
image format as your 'intermediary' would allow you to use any generic
encryption routine you like, while also allowing you to convert the
encrypted binary data to/from an image format of your choice (well,
your choice within the set of other formats for which NetPBM has
to/from converters available).
This frees you from having to understand the internal structure of the
various image formats. You just work with the netpbm format (a raw
binary bit/pixel block) for the encrypt/decrypt/padding operations, and
delegate all the "image format" complexity to the netpbm library.
Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > Stefan Claas wrote:
> > > Rich wrote:
> > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > Rich wrote:
> > > > >
> > > > > > If instead you mean some kind of "special, PNG aware,
> > > > > > encryptor that only encrypted the bitmap data of a PNG", but
> > > > > > left the file as otherwise a proper PNG image structure, then
> > > > > > that is slightly tricky (and an algorithm that is only useful
> > > > > > for PNG's alone).
> > > > >
> > > > > Yes, this is what I mean.
> > > >
> > > > Which brings up the question of: why?
> > > >
> > > > Why go to the trouble to create an encryptor that is specalized
> > > > for just encrypting the internal bitmap data within a PNG, leaving
> > > > the rest as a PNG file, when a generic "byte stream" encryptor
> > > > will encrypt the entire PNG with no extra effort?
> > >
> > > To make more content as allowed postable on social media, like X.
> >
> > I.e, first you put data with file2png in a .png and then encrypt it
> > to finally post it. I can do this now with my xorpic program, but I
> > thought a solution with AES-GCM or XChaCha20+ploy1305 is better.
>
> The "path" I outlined in my previous post, where you utilize the netpbm
> image format as your 'intermediary' would allow you to use any generic
> encryption routine you like, while also allowing you to convert the
> encrypted binary data to/from an image format of your choice (well,
> your choice within the set of other formats for which NetPBM has
> to/from converters available).
>
> This frees you from having to understand the internal structure of the
> various image formats. You just work with the netpbm format (a raw
> binary bit/pixel block) for the encrypt/decrypt/padding operations, and
> delegate all the "image format" complexity to the netpbm library.
Thank you! My ppmenc tool works nicely, here are the test images:
The big problem I face when converting the encryypted image to .png
and back a diff shows a difference and the decryption fails.
Maybe someone can figure out what to do, so that a converted .ppm
can be posted online , for viewers/readers and then can be converted
back to the original .ppm, which shows no difference.
--
Regards
Stefan
Stefan Claas <pollux@tilde.club> wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>> > Stefan Claas wrote:
>> > > Rich wrote:
>> > > > Stefan Claas <pollux@tilde.club> wrote:
>> > > > > Rich wrote:
>> > > > >
>> > > > > > If instead you mean some kind of "special, PNG aware,
>> > > > > > encryptor that only encrypted the bitmap data of a PNG",
>> > > > > > but left the file as otherwise a proper PNG image
>> > > > > > structure, then that is slightly tricky (and an algorithm
>> > > > > > that is only useful for PNG's alone).
>> > > > >
>> > > > > Yes, this is what I mean.
>> > > >
>> > > > Which brings up the question of: why?
>> > > >
>> > > > Why go to the trouble to create an encryptor that is
>> > > > specalized for just encrypting the internal bitmap data within
>> > > > a PNG, leaving the rest as a PNG file, when a generic "byte
>> > > > stream" encryptor will encrypt the entire PNG with no extra
>> > > > effort?
>> > >
>> > > To make more content as allowed postable on social media, like
>> > > X.
>> >
>> > I.e, first you put data with file2png in a .png and then encrypt
>> > it to finally post it. I can do this now with my xorpic program,
>> > but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
>> > better.
>>
>> The "path" I outlined in my previous post, where you utilize the
>> netpbm image format as your 'intermediary' would allow you to use
>> any generic encryption routine you like, while also allowing you to
>> convert the encrypted binary data to/from an image format of your
>> choice (well, your choice within the set of other formats for which
>> NetPBM has to/from converters available).
>>
>> This frees you from having to understand the internal structure of
>> the various image formats. You just work with the netpbm format (a
>> raw binary bit/pixel block) for the encrypt/decrypt/padding
>> operations, and delegate all the "image format" complexity to the
>> netpbm library.
>
> Thank you! My ppmenc tool works nicely, here are the test images:
>
> https://jmp.sh/HZM9ML9f
>
> The big problem I face when converting the encryypted image to .png
> and back a diff shows a difference and the decryption fails.
>
> Maybe someone can figure out what to do, so that a converted .ppm can
> be posted online , for viewers/readers and then can be converted back
> to the original .ppm, which shows no difference.
We can't read your mind over Usenet so can you show how you converted
the encrypted image to a png and back.
Rich wrote:
> Stefan Claas <pollux@tilde.club> wrote:
> > Rich wrote:
> > > Stefan Claas <pollux@tilde.club> wrote:
> > > > Stefan Claas wrote:
> > > > > Rich wrote:
> > > > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > > > Rich wrote:
> > > > > > >
> > > > > > > > If instead you mean some kind of "special, PNG aware,
> > > > > > > > encryptor that only encrypted the bitmap data of a PNG",
> > > > > > > > but left the file as otherwise a proper PNG image
> > > > > > > > structure, then that is slightly tricky (and an algorithm
> > > > > > > > that is only useful for PNG's alone).
> > > > > > >
> > > > > > > Yes, this is what I mean.
> > > > > >
> > > > > > Which brings up the question of: why?
> > > > > >
> > > > > > Why go to the trouble to create an encryptor that is
> > > > > > specalized for just encrypting the internal bitmap data within
> > > > > > a PNG, leaving the rest as a PNG file, when a generic "byte
> > > > > > stream" encryptor will encrypt the entire PNG with no extra
> > > > > > effort?
> > > > >
> > > > > To make more content as allowed postable on social media, like
> > > > > X.
> > > >
> > > > I.e, first you put data with file2png in a .png and then encrypt
> > > > it to finally post it. I can do this now with my xorpic program,
> > > > but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
> > > > better.
> > >
> > > The "path" I outlined in my previous post, where you utilize the
> > > netpbm image format as your 'intermediary' would allow you to use
> > > any generic encryption routine you like, while also allowing you to
> > > convert the encrypted binary data to/from an image format of your
> > > choice (well, your choice within the set of other formats for which
> > > NetPBM has to/from converters available).
> > >
> > > This frees you from having to understand the internal structure of
> > > the various image formats. You just work with the netpbm format (a
> > > raw binary bit/pixel block) for the encrypt/decrypt/padding
> > > operations, and delegate all the "image format" complexity to the
> > > netpbm library.
> >
> > Thank you! My ppmenc tool works nicely, here are the test images:
> >
> > https://jmp.sh/HZM9ML9f
> >
> > The big problem I face when converting the encryypted image to .png
> > and back a diff shows a difference and the decryption fails.
> >
> > Maybe someone can figure out what to do, so that a converted .ppm can
> > be posted online , for viewers/readers and then can be converted back
> > to the original .ppm, which shows no difference.
>
> We can't read your mind over Usenet so can you show how you converted
> the encrypted image to a png and back.
>
I used Gimp with compression set to 0 and the netbmp tools.
--
Regards
Stefan
On 1/5/2025 1:24 AM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/4/2025 4:21 PM, Stefan Claas wrote:
>>> Rich wrote:
>>>
>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>> (and an algorithm that is only useful for PNG's alone).
>>>
>>> Yes, this is what I mean.
>>>
>>
>> Well, take a good ol' bag o' bytes and turn it into a valid png?
>
> No, encrypt a .png, so that an encrypted noise image comes out.
>
Are you talking about encrypting something A. Taking the resulting
ciphertext B and creating a new png C out of B. The png C will have B a
a visual entity. Now, since C has the ciphertext B in it, we can decrypt
that data back into A.
Is this what you are doing?
On 1/5/2025 1:27 AM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/4/2025 4:19 PM, Stefan Claas wrote:
>>> Stefan Claas wrote:
>>>> Chris M. Thomasson wrote:
>>>>> On 1/4/2025 2:10 PM, Stefan Claas wrote:
>>>>>> Chris M. Thomasson wrote:
>>>>>>
>>>>>>> Now, for some fun wrt floating point issues... Have you messed around
>>>>>>> with storing data in the n-ary roots of complex numbers? they can
>>>>>>> actually create interesting renderings using real user data.
>>>>>>>
>>>>>>> https://groups.google.com/g/comp.lang.c++/c/bB1wA4wvoFc/m/ozDpUBlTAAAJ
>>>>>>>
>>>>>>> When you get really bored! ;^)
>>>>>>
>>>>>> Well, I no longer do Computer Graphics, with formulas, like for fractals
>>>>>> etc. , or 3D CGI and 3D printing. Not sure if I ever will return to that.
>>>>>>
>>>>>> The only interests with graphics is, when it comes to encryption/decryption
>>>>>> images.
>>>>>>
>>>>>
>>>>> Fwiw, do you like stereograms? I created some with some of my depth maps
>>>>> created in GLSL shaders. Can you see this one:
>>>>>
>>>>> https://i.ibb.co/gwHwpFL/image.png
>>>>
>>>> Yes, I can see it.
>>>>
>>>>> I have an idea about them. What about combining an anaglyph with a
>>>>> stereogram such that the observer would need to do the "eye trick" while
>>>>> wearing the red and blue glasses?
>>>>
>>>> I created in 1995, with Photoshop 2.5.1/3.0 a stereo image, which needs
>>>> red/blue glasses. :-) I uploaded it to rarible.com as NFT for 50 ETH,
>>>> but it is no longer there, nor on my harddrive. :-( It looked really
>>>> really cool and was called ORIGAMI.
>>>
>>> Well,I found it on rarible.com, sorry my mistake.
>>>
>>> <https://rarible.com/token/0xc9154424b823b10579895ccbe442d41b9abd96ed:33722708843760813648285509687083650090679594480478541226033658120821450735646>
>>>
>>> use the maginfying glass to see the original size and use red/blues glasses
>>> to see the effect. :-)
>>>
>>
>> :^) I found one of my older anaglyphs I knew I posted before. the left
>> hand side should seem to project "into" the screen, and the right one
>> out of it. Can you see with with your red and blue goggles? glasses,
>> lol. ;^) I had to use two cameras in my scene to do this. One for each
>> eye of the observer.
>>
>> https://i.ibb.co/qm3jg4z/image.png
>>
>> https://www.facebook.com/photo/?fbid=135603427598664&set=pcb.135603700931970
>
> I can not find my glasses. It's been many years since I have used them.
>
Shit happens! :^) For some damn reason I have mine right by my computer.
Strange in a sense. ;^)
Now, think of viewing a "special" stereogram that takes the "special"
depth map's red and blue color channels into account. I think that
viewing the stereogram/anaglyph hybrid thing would simply have to
involve the observer doing the eye thing _while_ wearing the glasses.
Afaict, it should be able to work. I think so.
On 1/5/2025 1:53 PM, Chris M. Thomasson wrote:
> On 1/5/2025 1:24 AM, Stefan Claas wrote:
>> Chris M. Thomasson wrote:
>>> On 1/4/2025 4:21 PM, Stefan Claas wrote:
>>>> Rich wrote:
>>>>
>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>
>>>> Yes, this is what I mean.
>>>>
>>>
>>> Well, take a good ol' bag o' bytes and turn it into a valid png?
>>
>> No, encrypt a .png, so that an encrypted noise image comes out.
>>
>
> Are you talking about encrypting something A. Taking the resulting
> ciphertext B and creating a new png C out of B. The png C will have B a
> a visual entity. Now, since C has the ciphertext B in it, we can decrypt
> that data back into A.
>
> Is this what you are doing?
We can send C (the png) out as an "image file" that holds B (the
ciphertext) as a "payload"?
On 1/5/2025 1:25 AM, Stefan Claas wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>>> Rich wrote:
>>>
>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>> (and an algorithm that is only useful for PNG's alone).
>>>
>>> Yes, this is what I mean.
>>
>> Which brings up the question of: why?
>>
>> Why go to the trouble to create an encryptor that is specalized for
>> just encrypting the internal bitmap data within a PNG, leaving the rest
>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>> entire PNG with no extra effort?
>
> To make more content as allowed postable on social media, like X.
>
Well, posting a png to say, facebook, well... It's probablly going to
turn it into a jpg... This can ruin the embedded ciphertext in the png
image...
On 1/5/2025 2:06 PM, Chris M. Thomasson wrote:
> On 1/5/2025 1:25 AM, Stefan Claas wrote:
>> Rich wrote:
>>> Stefan Claas <pollux@tilde.club> wrote:
>>>> Rich wrote:
>>>>
>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>
>>>> Yes, this is what I mean.
>>>
>>> Which brings up the question of: why?
>>>
>>> Why go to the trouble to create an encryptor that is specalized for
>>> just encrypting the internal bitmap data within a PNG, leaving the rest
>>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>>> entire PNG with no extra effort?
>>
>> To make more content as allowed postable on social media, like X.
>>
>
> Well, posting a png to say, facebook, well... It's probablly going to
> turn it into a jpg... This can ruin the embedded ciphertext in the png
> image...
Actually, the damn FB allows me to send my links with embedded
ciphertext just fine.
Chris M. Thomasson wrote:
> On 1/5/2025 2:06 PM, Chris M. Thomasson wrote:
> > On 1/5/2025 1:25 AM, Stefan Claas wrote:
> > > Rich wrote:
> > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > Rich wrote:
> > > > >
> > > > > > If instead you mean some kind of "special, PNG aware, encryptor that
> > > > > > only encrypted the bitmap data of a PNG", but left the file as
> > > > > > otherwise a proper PNG image structure, then that is slightly tricky
> > > > > > (and an algorithm that is only useful for PNG's alone).
> > > > >
> > > > > Yes, this is what I mean.
> > > >
> > > > Which brings up the question of: why?
> > > >
> > > > Why go to the trouble to create an encryptor that is specalized for
> > > > just encrypting the internal bitmap data within a PNG, leaving the rest
> > > > as a PNG file, when a generic "byte stream" encryptor will encrypt the
> > > > entire PNG with no extra effort?
> > >
> > > To make more content as allowed postable on social media, like X.
> > >
> >
> > Well, posting a png to say, facebook, well... It's probablly going to
> > turn it into a jpg... This can ruin the embedded ciphertext in the png
> > image...
>
> Actually, the damn FB allows me to send my links with embedded
> ciphertext just fine.
It is for X and not Meta.
--
Regards
Stefan
Chris M. Thomasson wrote:
> On 1/5/2025 1:24 AM, Stefan Claas wrote:
> > Chris M. Thomasson wrote:
> > > On 1/4/2025 4:21 PM, Stefan Claas wrote:
> > > > Rich wrote:
> > > >
> > > > > If instead you mean some kind of "special, PNG aware, encryptor that
> > > > > only encrypted the bitmap data of a PNG", but left the file as
> > > > > otherwise a proper PNG image structure, then that is slightly tricky
> > > > > (and an algorithm that is only useful for PNG's alone).
> > > >
> > > > Yes, this is what I mean.
> > > >
> > >
> > > Well, take a good ol' bag o' bytes and turn it into a valid png?
> >
> > No, encrypt a .png, so that an encrypted noise image comes out.
> >
>
> Are you talking about encrypting something A. Taking the resulting
> ciphertext B and creating a new png C out of B. The png C will have B a
> a visual entity. Now, since C has the ciphertext B in it, we can decrypt
> that data back into A.
>
> Is this what you are doing?
I am talking about .png image encryption. I got it working for ppm (P6)
files, so that when you have created with Gimp a ppm (raw) file it will
then be encrypted with a password and salt and results in a noise image.
Have you not seen my online folder with the example ... ???
--
Regards
Stefan
On 1/5/2025 2:21 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/5/2025 1:24 AM, Stefan Claas wrote:
>>> Chris M. Thomasson wrote:
>>>> On 1/4/2025 4:21 PM, Stefan Claas wrote:
>>>>> Rich wrote:
>>>>>
>>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>>
>>>>> Yes, this is what I mean.
>>>>>
>>>>
>>>> Well, take a good ol' bag o' bytes and turn it into a valid png?
>>>
>>> No, encrypt a .png, so that an encrypted noise image comes out.
>>>
>>
>> Are you talking about encrypting something A. Taking the resulting
>> ciphertext B and creating a new png C out of B. The png C will have B a
>> a visual entity. Now, since C has the ciphertext B in it, we can decrypt
>> that data back into A.
>>
>> Is this what you are doing?
>
> I am talking about .png image encryption. I got it working for ppm (P6)
> files, so that when you have created with Gimp a ppm (raw) file it will
> then be encrypted with a password and salt and results in a noise image.
>
> Have you not seen my online folder with the example ... ???
>
The PPM still needs it proper format to be a, as you say, noise image?
I have worked a lot with PPM's. Keep in mind that storing ciphertext for
any file, even the original PPM, JPG, ect, can be stored in another PPM
for sure. So, the resulting PPM will have the payload of any file,
another PPM, no problem. Then we can look at the payload as an image on
the screen.
On 1/5/2025 2:18 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/5/2025 2:06 PM, Chris M. Thomasson wrote:
>>> On 1/5/2025 1:25 AM, Stefan Claas wrote:
>>>> Rich wrote:
>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>> Rich wrote:
>>>>>>
>>>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>>>
>>>>>> Yes, this is what I mean.
>>>>>
>>>>> Which brings up the question of: why?
>>>>>
>>>>> Why go to the trouble to create an encryptor that is specalized for
>>>>> just encrypting the internal bitmap data within a PNG, leaving the rest
>>>>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>>>>> entire PNG with no extra effort?
>>>>
>>>> To make more content as allowed postable on social media, like X.
>>>>
>>>
>>> Well, posting a png to say, facebook, well... It's probablly going to
>>> turn it into a jpg... This can ruin the embedded ciphertext in the png
>>> image...
>>
>> Actually, the damn FB allows me to send my links with embedded
>> ciphertext just fine.
>
> It is for X and not Meta.
>
Well, sending say a PNG to X, it still might convert it into a JPG. It
might alter things for compression purposes. This can mess around with
your payload...
On 1/5/2025 2:18 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/5/2025 2:06 PM, Chris M. Thomasson wrote:
>>> On 1/5/2025 1:25 AM, Stefan Claas wrote:
>>>> Rich wrote:
>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>> Rich wrote:
>>>>>>
>>>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>>>
>>>>>> Yes, this is what I mean.
>>>>>
>>>>> Which brings up the question of: why?
>>>>>
>>>>> Why go to the trouble to create an encryptor that is specalized for
>>>>> just encrypting the internal bitmap data within a PNG, leaving the rest
>>>>> as a PNG file, when a generic "byte stream" encryptor will encrypt the
>>>>> entire PNG with no extra effort?
>>>>
>>>> To make more content as allowed postable on social media, like X.
>>>>
>>>
>>> Well, posting a png to say, facebook, well... It's probablly going to
>>> turn it into a jpg... This can ruin the embedded ciphertext in the png
>>> image...
>>
>> Actually, the damn FB allows me to send my links with embedded
>> ciphertext just fine.
>
> It is for X and not Meta.
>
I should actually join X and see if it allows me to post my ciphertext
links... FB works so far.
Chris M. Thomasson wrote:
> On 1/5/2025 2:21 PM, Stefan Claas wrote:
> > Chris M. Thomasson wrote:
> > > On 1/5/2025 1:24 AM, Stefan Claas wrote:
> > > > Chris M. Thomasson wrote:
> > > > > On 1/4/2025 4:21 PM, Stefan Claas wrote:
> > > > > > Rich wrote:
> > > > > >
> > > > > > > If instead you mean some kind of "special, PNG aware, encryptor that
> > > > > > > only encrypted the bitmap data of a PNG", but left the file as
> > > > > > > otherwise a proper PNG image structure, then that is slightly tricky
> > > > > > > (and an algorithm that is only useful for PNG's alone).
> > > > > >
> > > > > > Yes, this is what I mean.
> > > > > >
> > > > >
> > > > > Well, take a good ol' bag o' bytes and turn it into a valid png?
> > > >
> > > > No, encrypt a .png, so that an encrypted noise image comes out.
> > > >
> > >
> > > Are you talking about encrypting something A. Taking the resulting
> > > ciphertext B and creating a new png C out of B. The png C will have B a
> > > a visual entity. Now, since C has the ciphertext B in it, we can decrypt
> > > that data back into A.
> > >
> > > Is this what you are doing?
> >
> > I am talking about .png image encryption. I got it working for ppm (P6)
> > files, so that when you have created with Gimp a ppm (raw) file it will
> > then be encrypted with a password and salt and results in a noise image.
> >
> > Have you not seen my online folder with the example ... ???
> >
>
> The PPM still needs it proper format to be a, as you say, noise image?
Are you not reading the complete thread, in which I have replied to Rich?
> I have worked a lot with PPM's. Keep in mind that storing ciphertext for
> any file, even the original PPM, JPG, ect, can be stored in another PPM
> for sure. So, the resulting PPM will have the payload of any file,
> another PPM, no problem. Then we can look at the payload as an image on
> the screen.
Arrgh ... I am not talking about ciphertext or payload, I am talking about
*Image Encryption*! I had that already in the mid 90s as Photoshop plug-in,
from Japan.
--
Regards
Stefan
On 1/5/2025 2:40 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/5/2025 2:21 PM, Stefan Claas wrote:
>>> Chris M. Thomasson wrote:
>>>> On 1/5/2025 1:24 AM, Stefan Claas wrote:
>>>>> Chris M. Thomasson wrote:
>>>>>> On 1/4/2025 4:21 PM, Stefan Claas wrote:
>>>>>>> Rich wrote:
>>>>>>>
>>>>>>>> If instead you mean some kind of "special, PNG aware, encryptor that
>>>>>>>> only encrypted the bitmap data of a PNG", but left the file as
>>>>>>>> otherwise a proper PNG image structure, then that is slightly tricky
>>>>>>>> (and an algorithm that is only useful for PNG's alone).
>>>>>>>
>>>>>>> Yes, this is what I mean.
>>>>>>>
>>>>>>
>>>>>> Well, take a good ol' bag o' bytes and turn it into a valid png?
>>>>>
>>>>> No, encrypt a .png, so that an encrypted noise image comes out.
>>>>>
>>>>
>>>> Are you talking about encrypting something A. Taking the resulting
>>>> ciphertext B and creating a new png C out of B. The png C will have B a
>>>> a visual entity. Now, since C has the ciphertext B in it, we can decrypt
>>>> that data back into A.
>>>>
>>>> Is this what you are doing?
>>>
>>> I am talking about .png image encryption. I got it working for ppm (P6)
>>> files, so that when you have created with Gimp a ppm (raw) file it will
>>> then be encrypted with a password and salt and results in a noise image.
>>>
>>> Have you not seen my online folder with the example ... ???
>>>
>>
>> The PPM still needs it proper format to be a, as you say, noise image?
>
> Are you not reading the complete thread, in which I have replied to Rich?
>
>> I have worked a lot with PPM's. Keep in mind that storing ciphertext for
>> any file, even the original PPM, JPG, ect, can be stored in another PPM
>> for sure. So, the resulting PPM will have the payload of any file,
>> another PPM, no problem. Then we can look at the payload as an image on
>> the screen.
>
> Arrgh ... I am not talking about ciphertext or payload, I am talking about
> *Image Encryption*! I had that already in the mid 90s as Photoshop plug-in,
> from Japan.
>
Sorry. When I think of image encryption, it still makes me think of Tux.
Then we can think of an image of the letter A. We send an image of X,
and say the key is X = A. I am sorry for missing your main point.
On 1/5/2025 1:10 PM, Stefan Claas wrote:
> Rich wrote:
>> Stefan Claas <pollux@tilde.club> wrote:
>>> Rich wrote:
>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>> Stefan Claas wrote:
>>>>>> Rich wrote:
>>>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>>>> Rich wrote:
>>>>>>>>
>>>>>>>>> If instead you mean some kind of "special, PNG aware,
>>>>>>>>> encryptor that only encrypted the bitmap data of a PNG",
>>>>>>>>> but left the file as otherwise a proper PNG image
>>>>>>>>> structure, then that is slightly tricky (and an algorithm
>>>>>>>>> that is only useful for PNG's alone).
>>>>>>>>
>>>>>>>> Yes, this is what I mean.
>>>>>>>
>>>>>>> Which brings up the question of: why?
>>>>>>>
>>>>>>> Why go to the trouble to create an encryptor that is
>>>>>>> specalized for just encrypting the internal bitmap data within
>>>>>>> a PNG, leaving the rest as a PNG file, when a generic "byte
>>>>>>> stream" encryptor will encrypt the entire PNG with no extra
>>>>>>> effort?
>>>>>>
>>>>>> To make more content as allowed postable on social media, like
>>>>>> X.
>>>>>
>>>>> I.e, first you put data with file2png in a .png and then encrypt
>>>>> it to finally post it. I can do this now with my xorpic program,
>>>>> but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
>>>>> better.
>>>>
>>>> The "path" I outlined in my previous post, where you utilize the
>>>> netpbm image format as your 'intermediary' would allow you to use
>>>> any generic encryption routine you like, while also allowing you to
>>>> convert the encrypted binary data to/from an image format of your
>>>> choice (well, your choice within the set of other formats for which
>>>> NetPBM has to/from converters available).
>>>>
>>>> This frees you from having to understand the internal structure of
>>>> the various image formats. You just work with the netpbm format (a
>>>> raw binary bit/pixel block) for the encrypt/decrypt/padding
>>>> operations, and delegate all the "image format" complexity to the
>>>> netpbm library.
>>>
>>> Thank you! My ppmenc tool works nicely, here are the test images:
>>>
>>> https://jmp.sh/HZM9ML9f
>>>
>>> The big problem I face when converting the encryypted image to .png
>>> and back a diff shows a difference and the decryption fails.
>>>
>>> Maybe someone can figure out what to do, so that a converted .ppm can
>>> be posted online , for viewers/readers and then can be converted back
>>> to the original .ppm, which shows no difference.
>>
>> We can't read your mind over Usenet so can you show how you converted
>> the encrypted image to a png and back.
>>
>
> I used Gimp with compression set to 0 and the netbmp tools.
>
You should write your own program for it. The Gimp altered some bytes,
right?
On 1/5/2025 2:48 PM, Chris M. Thomasson wrote:
> On 1/5/2025 1:10 PM, Stefan Claas wrote:
>> Rich wrote:
>>> Stefan Claas <pollux@tilde.club> wrote:
>>>> Rich wrote:
>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>> Stefan Claas wrote:
>>>>>>> Rich wrote:
>>>>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>>>>> Rich wrote:
>>>>>>>>>
>>>>>>>>>> If instead you mean some kind of "special, PNG aware,
>>>>>>>>>> encryptor that only encrypted the bitmap data of a PNG",
>>>>>>>>>> but left the file as otherwise a proper PNG image
>>>>>>>>>> structure, then that is slightly tricky (and an algorithm
>>>>>>>>>> that is only useful for PNG's alone).
>>>>>>>>>
>>>>>>>>> Yes, this is what I mean.
>>>>>>>>
>>>>>>>> Which brings up the question of: why?
>>>>>>>>
>>>>>>>> Why go to the trouble to create an encryptor that is
>>>>>>>> specalized for just encrypting the internal bitmap data within
>>>>>>>> a PNG, leaving the rest as a PNG file, when a generic "byte
>>>>>>>> stream" encryptor will encrypt the entire PNG with no extra
>>>>>>>> effort?
>>>>>>>
>>>>>>> To make more content as allowed postable on social media, like
>>>>>>> X.
>>>>>>
>>>>>> I.e, first you put data with file2png in a .png and then encrypt
>>>>>> it to finally post it. I can do this now with my xorpic program,
>>>>>> but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
>>>>>> better.
>>>>>
>>>>> The "path" I outlined in my previous post, where you utilize the
>>>>> netpbm image format as your 'intermediary' would allow you to use
>>>>> any generic encryption routine you like, while also allowing you to
>>>>> convert the encrypted binary data to/from an image format of your
>>>>> choice (well, your choice within the set of other formats for which
>>>>> NetPBM has to/from converters available).
>>>>>
>>>>> This frees you from having to understand the internal structure of
>>>>> the various image formats. You just work with the netpbm format (a
>>>>> raw binary bit/pixel block) for the encrypt/decrypt/padding
>>>>> operations, and delegate all the "image format" complexity to the
>>>>> netpbm library.
>>>>
>>>> Thank you! My ppmenc tool works nicely, here are the test images:
>>>>
>>>> https://jmp.sh/HZM9ML9f
>>>>
>>>> The big problem I face when converting the encryypted image to .png
>>>> and back a diff shows a difference and the decryption fails.
>>>>
>>>> Maybe someone can figure out what to do, so that a converted .ppm can
>>>> be posted online , for viewers/readers and then can be converted back
>>>> to the original .ppm, which shows no difference.
>>>
>>> We can't read your mind over Usenet so can you show how you converted
>>> the encrypted image to a png and back.
>>>
>>
>> I used Gimp with compression set to 0 and the netbmp tools.
>>
>
> You should write your own program for it. The Gimp altered some bytes,
> right?
Fwiw, the Cairo lib is fairly nice, well, to me at least... I use it a
lot for my 2d work. it allows you to gain access to the raw underlying
buffer. So, I can create PNG's with payloads that are intact.
Chris M. Thomasson wrote:
> On 1/5/2025 2:48 PM, Chris M. Thomasson wrote:
> > On 1/5/2025 1:10 PM, Stefan Claas wrote:
> > > Rich wrote:
> > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > Rich wrote:
> > > > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > > > Stefan Claas wrote:
> > > > > > > > Rich wrote:
> > > > > > > > > Stefan Claas <pollux@tilde.club> wrote:
> > > > > > > > > > Rich wrote:
> > > > > > > > > >
> > > > > > > > > > > If instead you mean some kind of "special, PNG aware,
> > > > > > > > > > > encryptor that only encrypted the bitmap data of a PNG",
> > > > > > > > > > > but left the file as otherwise a proper PNG image
> > > > > > > > > > > structure, then that is slightly tricky (and an algorithm
> > > > > > > > > > > that is only useful for PNG's alone).
> > > > > > > > > >
> > > > > > > > > > Yes, this is what I mean.
> > > > > > > > >
> > > > > > > > > Which brings up the question of: why?
> > > > > > > > >
> > > > > > > > > Why go to the trouble to create an encryptor that is
> > > > > > > > > specalized for just encrypting the internal bitmap data within
> > > > > > > > > a PNG, leaving the rest as a PNG file, when a generic "byte
> > > > > > > > > stream" encryptor will encrypt the entire PNG with no extra
> > > > > > > > > effort?
> > > > > > > >
> > > > > > > > To make more content as allowed postable on social media, like
> > > > > > > > X.
> > > > > > >
> > > > > > > I.e, first you put data with file2png in a .png and then encrypt
> > > > > > > it to finally post it. I can do this now with my xorpic program,
> > > > > > > but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
> > > > > > > better.
> > > > > >
> > > > > > The "path" I outlined in my previous post, where you utilize the
> > > > > > netpbm image format as your 'intermediary' would allow you to use
> > > > > > any generic encryption routine you like, while also allowing you to
> > > > > > convert the encrypted binary data to/from an image format of your
> > > > > > choice (well, your choice within the set of other formats for which
> > > > > > NetPBM has to/from converters available).
> > > > > >
> > > > > > This frees you from having to understand the internal structure of
> > > > > > the various image formats. You just work with the netpbm format (a
> > > > > > raw binary bit/pixel block) for the encrypt/decrypt/padding
> > > > > > operations, and delegate all the "image format" complexity to the
> > > > > > netpbm library.
> > > > >
> > > > > Thank you! My ppmenc tool works nicely, here are the test images:
> > > > >
> > > > > https://jmp.sh/HZM9ML9f
> > > > >
> > > > > The big problem I face when converting the encryypted image to .png
> > > > > and back a diff shows a difference and the decryption fails.
> > > > >
> > > > > Maybe someone can figure out what to do, so that a converted .ppm can
> > > > > be posted online , for viewers/readers and then can be converted back
> > > > > to the original .ppm, which shows no difference.
> > > >
> > > > We can't read your mind over Usenet so can you show how you converted
> > > > the encrypted image to a png and back.
> > > >
> > >
> > > I used Gimp with compression set to 0 and the netbmp tools.
> > >
> >
> > You should write your own program for it. The Gimp altered some bytes,
> > right?
>
> Fwiw, the Cairo lib is fairly nice, well, to me at least... I use it a
> lot for my 2d work. it allows you to gain access to the raw underlying
> buffer. So, I can create PNG's with payloads that are intact.
Ok, here is the deal ... I have file2png (Go and Python3) which converts
any (encrypted) payload to valid noise .png images and back. I have xorpng
in Go which can create .png keys of random noise (crypto/rand) and xor
then .png images with them, to create encrypted noise images. I have ppmenc
in Go which encrypts ppm (P6) images to noise images. What I can not work
out is to convert a ppm to .png and back to the *original* .ppm (P6) file,
because .png with programs used or the Go library alter the conversion,
back to .ppm (P6). I tried many things and always failed.
*Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
and see if you can get the *original* data back. The sci.crypt community
and me of course would appreciate your help very much!
--
Regards
Stefan
On 1/5/2025 3:06 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
>> On 1/5/2025 2:48 PM, Chris M. Thomasson wrote:
>>> On 1/5/2025 1:10 PM, Stefan Claas wrote:
>>>> Rich wrote:
>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>> Rich wrote:
>>>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>>>> Stefan Claas wrote:
>>>>>>>>> Rich wrote:
>>>>>>>>>> Stefan Claas <pollux@tilde.club> wrote:
>>>>>>>>>>> Rich wrote:
>>>>>>>>>>>
>>>>>>>>>>>> If instead you mean some kind of "special, PNG aware,
>>>>>>>>>>>> encryptor that only encrypted the bitmap data of a PNG",
>>>>>>>>>>>> but left the file as otherwise a proper PNG image
>>>>>>>>>>>> structure, then that is slightly tricky (and an algorithm
>>>>>>>>>>>> that is only useful for PNG's alone).
>>>>>>>>>>>
>>>>>>>>>>> Yes, this is what I mean.
>>>>>>>>>>
>>>>>>>>>> Which brings up the question of: why?
>>>>>>>>>>
>>>>>>>>>> Why go to the trouble to create an encryptor that is
>>>>>>>>>> specalized for just encrypting the internal bitmap data within
>>>>>>>>>> a PNG, leaving the rest as a PNG file, when a generic "byte
>>>>>>>>>> stream" encryptor will encrypt the entire PNG with no extra
>>>>>>>>>> effort?
>>>>>>>>>
>>>>>>>>> To make more content as allowed postable on social media, like
>>>>>>>>> X.
>>>>>>>>
>>>>>>>> I.e, first you put data with file2png in a .png and then encrypt
>>>>>>>> it to finally post it. I can do this now with my xorpic program,
>>>>>>>> but I thought a solution with AES-GCM or XChaCha20+ploy1305 is
>>>>>>>> better.
>>>>>>>
>>>>>>> The "path" I outlined in my previous post, where you utilize the
>>>>>>> netpbm image format as your 'intermediary' would allow you to use
>>>>>>> any generic encryption routine you like, while also allowing you to
>>>>>>> convert the encrypted binary data to/from an image format of your
>>>>>>> choice (well, your choice within the set of other formats for which
>>>>>>> NetPBM has to/from converters available).
>>>>>>>
>>>>>>> This frees you from having to understand the internal structure of
>>>>>>> the various image formats. You just work with the netpbm format (a
>>>>>>> raw binary bit/pixel block) for the encrypt/decrypt/padding
>>>>>>> operations, and delegate all the "image format" complexity to the
>>>>>>> netpbm library.
>>>>>>
>>>>>> Thank you! My ppmenc tool works nicely, here are the test images:
>>>>>>
>>>>>> https://jmp.sh/HZM9ML9f
>>>>>>
>>>>>> The big problem I face when converting the encryypted image to .png
>>>>>> and back a diff shows a difference and the decryption fails.
>>>>>>
>>>>>> Maybe someone can figure out what to do, so that a converted .ppm can
>>>>>> be posted online , for viewers/readers and then can be converted back
>>>>>> to the original .ppm, which shows no difference.
>>>>>
>>>>> We can't read your mind over Usenet so can you show how you converted
>>>>> the encrypted image to a png and back.
>>>>>
>>>>
>>>> I used Gimp with compression set to 0 and the netbmp tools.
>>>>
>>>
>>> You should write your own program for it. The Gimp altered some bytes,
>>> right?
>>
>> Fwiw, the Cairo lib is fairly nice, well, to me at least... I use it a
>> lot for my 2d work. it allows you to gain access to the raw underlying
>> buffer. So, I can create PNG's with payloads that are intact.
>
> Ok, here is the deal ... I have file2png (Go and Python3) which converts
> any (encrypted) payload to valid noise .png images and back. I have xorpng
> in Go which can create .png keys of random noise (crypto/rand) and xor
> then .png images with them, to create encrypted noise images. I have ppmenc
> in Go which encrypts ppm (P6) images to noise images. What I can not work
> out is to convert a ppm to .png and back to the *original* .ppm (P6) file,
> because .png with programs used or the Go library alter the conversion,
> back to .ppm (P6). I tried many things and always failed.
>
> *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> and see if you can get the *original* data back. The sci.crypt community
> and me of course would appreciate your help very much!
>
I can, but I am busy with other things. I wrote a PPM reader a long time
ago. decades. Just parse the PPM (P6) format. Here is a program I wrote
in C that stores PPM's as a series of slices for a 3d volumetric object.
The ct_canvas_save_ppm creates a PPM. The fun part is that the image
stack is a volumetric object that can even be made into a hologram.
_______________________
/*
A Simple 2d Plane For Owen, with proper aspect ratios!
Color adder, single channel
By: Chris M. Thomasson
*_____________________________________________________________*/
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>
#include <stdbool.h>
#define CT_WIDTH 1920
#define CT_HEIGHT 1080
#define CT_N 10000000
struct ct_rgb
{
unsigned char r;
unsigned char g;
unsigned char b;
};
struct ct_canvas
{
unsigned long width;
unsigned long height;
//unsigned char* buf;
struct ct_rgb* buf;
};
bool
ct_canvas_create(
struct ct_canvas* const self,
unsigned long width,
unsigned long height
){
size_t size = width * height * sizeof(*self->buf);
self->buf = calloc(1, size);
if (self->buf)
{
self->width = width;
self->height = height;
return true;
}
return false;
}
void
ct_canvas_destroy(
struct ct_canvas const* const self
){
free(self->buf);
}
bool
ct_canvas_save_ppm(
struct ct_canvas const* const self,
char const* fname
){
FILE* fout = fopen(fname, "wb");
if (fout)
{
// P6 by Bart over on:
//
https://groups.google.com/forum/#!original/comp.lang.c/4196m3Raggs/2moZ67o5EwAJ
char const ppm_head[] =
"P6\n"
"# Chris M. Thomasson Simple 2d Plane ver:0.0.0.0 (pre-alpha)";
fprintf(fout, "%s\n%lu %lu\n%u\n",
ppm_head,
self->width, self->height,
255U);
size_t size = self->width * self->height;
for (size_t i = 0; i < size; ++i)
{
//unsigned int c = self->buf[i];
struct ct_rgb* c = self->buf + i;
fprintf(fout, "%c%c%c", c->r, c->g, c->b);
//fprintf(fout, "%c%c%c", c, 0U, 0U);
}
if (! fclose(fout))
{
return true;
}
}
return false;
}
struct ct_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};
struct ct_axes
ct_axes_from_point(
double complex z,
double radius
){
struct ct_axes axes = {
creal(z) - radius, creal(z) + radius,
cimag(z) - radius, cimag(z) + radius
};
return axes;
}
struct ct_plane
{
struct ct_axes axes;
double xstep;
double ystep;
};
void
ct_plane_init(
struct ct_plane* const self,
struct ct_axes const* axes,
unsigned long width,
unsigned long height
){
self->axes = *axes;
double awidth = self->axes.xmax - self->axes.xmin;
double aheight = self->axes.ymax - self->axes.ymin;
On 1/5/2025 3:06 PM, Stefan Claas wrote:
> Chris M. Thomasson wrote:
[...]
> *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> and see if you can get the *original* data back. The sci.crypt community
> and me of course would appreciate your help very much!
Still, try this:
Upload a PNG to X and/or FB. Copy the image, download the image from
them after its up on their site. Do a file compare on it wrt your
original source PNG. Are the exactly the same?
On 1/5/2025 3:14 PM, Chris M. Thomasson wrote:
[...]
Ooops, I don't think that is my animation slice code, it just creates a
single frame. This one create multiple slices, or frames of the
volumetric if you will:
ct_anime is the function of interest.
Sorry about that:
____________________________________
/*
Experimental Power Stack Mandelbulb for Owen
By: Chris M. Thomasson
*_____________________________________________________________*/
#include <stdlib.h>
#include <stdio.h>
#include <assert.h>
#include <complex.h>
#include <tgmath.h>
#include <stdbool.h>
#define CT_WIDTH 256 // width of plane
#define CT_HEIGHT 256 // height of plane
#define CT_FRAMES 256 // slices of the mbulb
#define CT_ITERS 64 // iterations per pixel
/* The Canvas
___________________________________*/
struct ct_rgb
{
unsigned char r;
unsigned char g;
unsigned char b;
};
struct ct_canvas
{
unsigned long width;
unsigned long height;
struct ct_rgb* buf;
};
bool
ct_canvas_create(
struct ct_canvas* const self,
unsigned long width,
unsigned long height
){
size_t size = width * height * sizeof(*self->buf);
self->buf = calloc(1, size);
if (self->buf)
{
self->width = width;
self->height = height;
return true;
}
return false;
}
void
ct_canvas_destroy(
struct ct_canvas const* const self
){
free(self->buf);
}
bool
ct_canvas_save_ppm(
struct ct_canvas const* const self,
char const* fname
){
FILE* fout = fopen(fname, "wb");
if (fout)
{
char const ppm_head[] =
"P6\n"
"# Chris M. Thomasson Simple 2d Plane ver:0.0.0.0 (pre-alpha)";
fprintf(fout, "%s\n%lu %lu\n%u\n",
ppm_head,
self->width, self->height,
255U);
size_t size = self->width * self->height;
for (size_t i = 0; i < size; ++i)
{
//unsigned int c = self->buf[i];
struct ct_rgb* c = self->buf + i;
fprintf(fout, "%c%c%c", c->r, c->g, c->b);
}
if (! fclose(fout))
{
return true;
}
}
return false;
}
/* The Axes
___________________________________*/
struct ct_axes
{
double xmin;
double xmax;
double ymin;
double ymax;
};
struct ct_axes
ct_axes_from_point(
double complex z,
double radius
){
struct ct_axes axes = {
creal(z) - radius, creal(z) + radius,
cimag(z) - radius, cimag(z) + radius
};
return axes;
}
/* The Plane
___________________________________*/
struct ct_plane
{
struct ct_axes axes;
double xstep;
double ystep;
};
void
ct_plane_init(
struct ct_plane* const self,
struct ct_axes const* axes,
unsigned long width,
unsigned long height
){
self->axes = *axes;
double awidth = self->axes.xmax - self->axes.xmin;
double aheight = self->axes.ymax - self->axes.ymin;
assert(width > 0 && height > 0 && awidth > 0.0);
double daspect = fabs((double)height / width);
double waspect = fabs(aheight / awidth);
if (daspect > waspect)
{
double excess = aheight * (daspect / waspect - 1.0);
self->axes.ymax += excess / 2.0;
self->axes.ymin -= excess / 2.0;
}
else if (daspect < waspect)
{
double excess = awidth * (waspect / daspect - 1.0);
self->axes.xmax += excess / 2.0;
self->axes.xmin -= excess / 2.0;
}
self->xstep = (self->axes.xmax - self->axes.xmin) / width;
self->ystep = (self->axes.ymax - self->axes.ymin) / height;
}
/* The Plot
___________________________________*/
struct ct_plot
{
struct ct_plane plane;
struct ct_canvas* canvas;
};
void
ct_plot_init(
struct ct_plot* const self,
struct ct_axes const* axes,
struct ct_canvas* canvas
){
ct_plane_init(&self->plane, axes, canvas->width - 1, canvas->height
- 1);
self->canvas = canvas;
}
bool
ct_plot_add(
struct ct_plot* const self,
double complex z,
struct ct_rgb const* color
){
long x = (creal(z) - self->plane.axes.xmin) / self->plane.xstep;
long y = (self->plane.axes.ymax - cimag(z)) / self->plane.ystep;
if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;
assert(i < self->canvas->height * self->canvas->width);
struct ct_rgb exist = self->canvas->buf[i];
exist.r += 1;
self->canvas->buf[i] = exist;
return true;
}
return true;
}
bool
ct_plot_pixel(
struct ct_plot* const self,
long x,
long y,
struct ct_rgb const* color
){
if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;
assert(i < self->canvas->height * self->canvas->width);
self->canvas->buf[i] = *color;
return true;
}
return false;
}
void
ct_plot_clear(
struct ct_plot* const self,
struct ct_rgb const* color
){
size_t size = self->canvas->height * self->canvas->width;
for (size_t i = 0; i < size; ++i)
{
self->canvas->buf[i] = *color;
}
}
double complex
ct_project_to_xy(
struct ct_plot* const self,
long x,
long y
){
double complex p =
(self->plane.axes.xmin + x * self->plane.xstep) +
(self->plane.axes.ymax - y * self->plane.ystep) * I;
return p;
}
bool
ct_plot_point(
struct ct_plot* const self,
double complex z,
struct ct_rgb const* color
){
long x = (creal(z) - self->plane.axes.xmin) / self->plane.xstep;
long y = (self->plane.axes.ymax - cimag(z)) / self->plane.ystep;
if (x > -1 && x < (long)self->canvas->width &&
y > -1 && y < (long)self->canvas->height)
{
// Now, we can convert to index.
size_t i = x + y * self->canvas->width;
assert(i < self->canvas->height * self->canvas->width);
self->canvas->buf[i] = *color;
return true;
}
return false;
}
// slow, so what for now... ;^)
void ct_circle(
struct ct_plot* const plot,
double complex c,
double radius,
unsigned int n
){
double abase = 6.2831853071 / n;
for (unsigned int i = 0; i < n; ++i)
{
double angle = abase * i;
double complex z =
(creal(c) + cos(angle) * radius) +
(cimag(c) + sin(angle) * radius) * I;
struct ct_rgb rgb = { 255, 255, 255 };
ct_plot_point(plot, z, &rgb);
}
}
/* Simple vec3 for just what I need
___________________________________*/
struct ct_vec3
{
double x;
double y;
double z;
};
double ct_vev3_length(
struct ct_vec3 const p
){
double sum = p.x * p.x + p.y * p.y + p.z * p.z;
return sqrt(sum);
}
struct ct_vec3
ct_vec3_add(
struct ct_vec3 const p,
struct ct_vec3 const addend
){
struct ct_vec3 sum = {
p.x + addend.x,
p.y + addend.y,
p.z + addend.z
};
return sum;
}
/* The Power Stack Mandelbulb
___________________________________*/
void
ct_iterate_mbulb_pixel(
struct ct_plot* const plot,
struct ct_vec3 const z0,
struct ct_vec3 const c0,
double power,
long x,
long y,
unsigned int n
){
struct ct_vec3 zs = z0;
struct ct_vec3 cs = c0;
for (unsigned long i = 0; i < n; ++i)
{
double r = ct_vev3_length(zs);
double rpower = pow(r, power);
double angle0 = atan2(zs.z, sqrt(zs.x * zs.x + zs.y * zs.y));
double angle1 = atan2(zs.y, zs.x);
struct ct_vec3 znew;
znew.x = rpower * cos(power * angle1) * cos(power * angle0);
znew.y = rpower * sin(power * angle1) * cos(power * angle0);
znew.z = rpower * sin(power * angle0);
Chris M. Thomasson wrote:
> On 1/5/2025 3:06 PM, Stefan Claas wrote:
> > Chris M. Thomasson wrote:
> [...]
> > *Please* try to write a .ppm (P6) to .png converter (and back) in C(++)
> > and see if you can get the *original* data back. The sci.crypt community
> > and me of course would appreciate your help very much!
>
> Still, try this:
>
> Upload a PNG to X and/or FB. Copy the image, download the image from
> them after its up on their site. Do a file compare on it wrt your
> original source PNG. Are the exactly the same?
On X they are the same, once downloaded, which a 'diff' shows. ;-)
--
Regards
Stefan
Pages:12345 |